Hi -- I notice in 2.4 kernels that there's a delay between completion of
"modprobe scanner" and when the device file can be successfully opened. I'm
working on code to power-up devices on-demand.
I've played some with making scripts to work around this, like
heyu turn on scanner
modprobe scanner
sleep 15
xsane
This is pretty gross, since I have to determine the "15" by playing with it,
and I'm sure it will fail some of the time unless I make it reeeeeally long. I
suspected this was some hardware issue -- USB latencies on device discovery, or
boot time for the scanner -- but a friend who isn't attempting to power-up his
devices says he sees the same behavior when just scripting "modprobe". So it
appears there's some fairly long delay in the kernel itself.
Anyone know off-hand what causes this delay, or if there's some way to get
the open() to block?
(btw, I'm not subscribed to the list).
b.c.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 15 Sep 2002 02:42, Brian Craft wrote:
<snip>
> This is pretty gross, since I have to determine the "15" by playing with
> it, and I'm sure it will fail some of the time unless I make it reeeeeally
> long. I suspected this was some hardware issue -- USB latencies on device
> discovery, or boot time for the scanner -- but a friend who isn't
> attempting to power-up his devices says he sees the same behavior when just
> scripting "modprobe". So it appears there's some fairly long delay in the
> kernel itself.
>
> Anyone know off-hand what causes this delay, or if there's some way to get
> the open() to block?
There is a fundamental problem with the way hotplugging works in this case.
The underlying hardware (in this case USB) detects a status change. It calls
call_usermode_helper(), and hands off the task to keventd. Then things wait.
Eventually keventd gets around to calling /sbin/hotplug, which loads modules,
runs scripts, writes config files, exec code - whatever. The problem is that
if module initialisation isn't complete, then clearly its interfaces may not
be established (or in some badly-coded cases, may contain races where the
interface is registered but isn't valid).
After discussions with Oliver Neukem at Linux Kongress, the idea of a second
hotplug event emerges. This is signalled by the driver that actually
registers the interface after the interface is properly established (so in
your example, USB core does one call_usermode_helper(), which probably does
something like "modprobe scanner"; and the scanner driver does a second
call_usermode_helper(), which loads xsane).
BTW: I'm not sure who actually came up with the idea - it was in the hotplug
BoF, but I missed this part of it.
Solves this race. Unfortunately requires some janitorial work. Patch away...
Brad
- --
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9hBmtW6pHgIdAuOMRAsblAKCKoiHGDnKnCU3kORyTJKEy8sjPKwCfSwDj
QGrrS/elmJ/YbBwmpksI+WU=
=yclZ
-----END PGP SIGNATURE-----
On Sun, Sep 15, 2002 at 03:25:01PM +1000, Brad Hards wrote:
>
> After discussions with Oliver Neukem at Linux Kongress, the idea of a second
> hotplug event emerges. This is signalled by the driver that actually
> registers the interface after the interface is properly established (so in
> your example, USB core does one call_usermode_helper(), which probably does
> something like "modprobe scanner"; and the scanner driver does a second
> call_usermode_helper(), which loads xsane).
This "second" hotplug event will happen when the driver registers with
the "class". So for the example of the USB scanner driver, it registers
itself with the USB "class" to set up the file_ops structure (this is
done in usb_register_dev(). At that point in time, /sbin/hotplug will
be called again.
Ok, the scanner driver isn't the best example, as it's both a USB
device, and uses the USB class interface. A better example would be a
USB keyboard, which would get the USB device /sbin/hotplug call when it
is first seen, and then after the driver is loaded, and registered with
the input layer, a input layer class event would be called through
/sbin/hotplug. And right now, there is the start of input class support
in the 2.5 kernel, if people want to play with it.
> BTW: I'm not sure who actually came up with the idea - it was in the hotplug
> BoF, but I missed this part of it.
I'm pretty sure it's documented in Pat Mochel's OLS 2002 paper. If not,
I know we talked about it at the OLS and Kernel Summit talks about
device naming and driverfs.
> Solves this race. Unfortunately requires some janitorial work. Patch away...
I have a patch around here somewhere for this, for the USB class only,
but I've been focusing on the struct device_driver work lately. After
that's done, I'll be adding class support (and the /sbin/hotplug class
support). But I'd gladly accept help if anyone's offering :)
thanks,
greg k-h
On Sun, Sep 15, 2002 at 03:25:01PM +1000, Brad Hards wrote:
>
> BTW: I'm not sure who actually came up with the idea - it was in the hotplug
> BoF, but I missed this part of it.
Oh, and are there any online records of what happened at this BoF? I
know I'm curious as to what happened there, and I'm sure that others are
too.
thanks,
greg k-h
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 15 Sep 2002 16:10, Greg KH wrote:
> This "second" hotplug event will happen when the driver registers with
> the "class". So for the example of the USB scanner driver, it registers
> itself with the USB "class" to set up the file_ops structure (this is
> done in usb_register_dev(). At that point in time, /sbin/hotplug will
> be called again.
This is too soon, at least for the scanner driver. Look at how much code runs
in scanner_probe() between the fops registration and the devfs registration.
Hmmm, that is probably a race anyway. Oliver?
Brad
- --
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9hCroW6pHgIdAuOMRAgJpAJ9WpQ66Oj5v7zaXqxqqTvVVhiukqACeJ3IP
T2oB/3+HODH36m9gSivzERw=
=Ov+1
-----END PGP SIGNATURE-----
On Sun, Sep 15, 2002 at 04:38:32PM +1000, Brad Hards wrote:
> On Sun, 15 Sep 2002 16:10, Greg KH wrote:
> > This "second" hotplug event will happen when the driver registers with
> > the "class". So for the example of the USB scanner driver, it registers
> > itself with the USB "class" to set up the file_ops structure (this is
> > done in usb_register_dev(). At that point in time, /sbin/hotplug will
> > be called again.
> This is too soon, at least for the scanner driver. Look at how much code runs
> in scanner_probe() between the fops registration and the devfs registration.
>
> Hmmm, that is probably a race anyway. Oliver?
You're right, that is a race. And is due to the historical fact that
usb_register() used to also register the fops structure at the same
time. Now that the functions are split apart, the call to
usb_register_dev() should be done at the same place as the call to
devfs_register(). Patches gladly accepted :)
thanks,
greg k-h