Am 20:59, schrieb Marco d'Itri:
I think the problem is that people keep wasting my time and their time
by attributing to udev the alleged bugs of other packages.
Hi, this is Upstream. Sorry, that was not my intention.
For a start, usb_modeswitch is broken because it expects /usr/bin/tclsh
(and /usr/bin/logger, and /var/log/ and probably more) to be available
at boot time.
O.K., I admit I never bothered much to think about the boot phase. I
just try to make new devices work that are unknown to the systems
and the kernels. And these sticks are typically used "ad hoc" on a
running system.
Because in my user support work I deal mostly with "non-techies"
often trying to get the latest hardware working, I *need* a
debugging/logging facility with relativly simple access, booting or not.
So I'm afraid I need your advice about several things to do it right.
Q: Is there a guideline what *can* be assumed available at boot time?
To the usb_modeswitch maintainer: please also remove from the script
crap like the recursive greps over /etc/udev/rules.d /lib/udev/rules.d
which make the boot unnecessarily slower. If this is needed because
another package is buggy then have if fixed and add a conflict.
Will do. The conflicts are now gone anyway from udev-extras if I'm
not mistaken.
And unless I am missing something, the usage of /tmp/gsmmodem_* is
insecure (if confirmed, please clone the bug and contact the security
team). And expected to *not* work at boot time. And subject to races.
And just plain ugly. What did the author think?
I thought I'd make the life easier for users. And yes, it is a quick
hack.
Maybe you can advise me here too:
These switchable modems often expose more than one vendor class
interface. If a serial driver is bound to them, each results in a
ttyUSB device. Usually only one of them - which has a transfer type
of "interrupt" - is suitable for the actual connection. Some have
more of these interrupt interfaces though; empiric knowledge says
the lower interface number is right.
My hack made udev create a symlink to the lowest interrupt interface
after mode-switching. To handle the switched device exclusively
(i.e. leaving any existing devices alone), I am storing just the
bus/device number in the temporary file name.
I did this only because I found no immediate way to signal
information from one udev RUN to the next; I'd be happy to scrap the
temporary file if it could be done via something like an environment
variable (but I tried that already).
I would *really* welcome any tips regarding a better way ...
Last but not least, if the program started by a RUN rule really needs to
sleep multiple times (hint: probably not with a modern kernel) then it
must fork and daemonize.
I thought the forking is done in the script head ? It does not block
udev on my systems ...
Regarding modern kernels, this tool is used on old netbooks, on
routers and sometimes dated distributions. Unfortunately, I can't
assume a certain kernel version nor a distribution minimum.
Sometimes there are existing udev rules or kernel routines to switch
the mode, so I wait a bit for these to kick in first. In some cases
I have to wait for a storage device to be accessible, to read out
SCSI attributes for identification.
After the mode switch I wait for any driver binding to the device;
if this doesn't happen I add the USB ID on the fly to the serial driver.
There are many aspects of these devices that are non-standard. But
I'm willing to work to make this package "unbroken".
Regards,
Josua Dietze
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
