Re: Firmware class breaks udev

[Kay Sievers <kay.sievers@vrfy.org>]

On Tue, 2005-03-15 at 14:09 +0100, Hannes Reinecke wrote:
> Kay Sievers wrote:
> > On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:

> >>If you have a look at the firmware class you'll see exactly what happens:
> >>The class insists on sending their own firmware events during
> >>initialisation. This code is typically executed during device probing,
> >>so the modprobe for this device will still be running when the firmware
> >>event is triggered.
> > 
> > But as soon as modprobe finishes, which should happen in the same
> > second, the class/firmware event should be started. How can this happen?
> > We have usually 10 seconds to upload firmware.
> > 
> This is not what happens.
> modprobe will return _after_ device initialisation finished, ie after
> the firmware is loaded (or not, as the case might be).
> The firmware event is triggered when modprobe is still running, so udev
> thinks the device is still initialising and waits until modprobe returns
> before executing that event.

Ick, I expected modprobe to return. This is what I saw the last time
with the ipw2100 driver. 

> As no firmware is loaded (the firmware event is still in the exec queue
> waiting for modprobe to return), firmware class eventually timeouts.
> Then modprobe returns, causing the firmware event to be executed.
> But by then the timeout has already been triggered and the upload will fail.
> 
> Increasing the timeout to '0' will only cause udev to wait forever.

Cause modprobe will wait forever here? If modprobe is called from an
udev process, udev will kill itself after 2 minutes. :)

> >>Which is also why you're seeing this only when using the events
> >>themselves, as when executing modprobe directly udev is only started for
> >> the firmware event, which will succeed as no physical device event is
> >>in the queue.
> >>
> >>For now I'll be putting in a quick exit for firmware events (ie not wait
> >>for the devices initialisation to finish) but this is nevertheless _nasty_.
> > 
> > The time I stumbled across a similar problem with the firmware class, I
> > thought about adding a TIMEOUT= to the hotplug environment which udev
> > can use to prioritize such events. But we should better replace
> > class_firmware.
> > 
> That's what i thought also. (That's why I named the variable 'timeout').

You have put that into the kernel hotplug env? Or udev itself?

> >>Currently the firmware class is definitely not compliant to the driver
> >>model.
> > 
> > Yes, it is a dirty ugly hack: It suppresses the kobj_add event with a
> > hotplug filter, later switches off the hotplug filter and creates a new
> > event by itself. I have several oopses recorded with the current
> > firmware_class if we still access the data file while the timeout
> > happens. 
> > 
> No wonder.
> 
> >>So either we should fix the firmware class or extend the driver
> >>model to allow for such beasts; Kay, your kobj hotplug extension might
> >>be a way to go.
> > 
> > I stumbled across this while trying a new way of loading userspace data
> > into the kernel. And I wanted control over the hotplug events. The
> > kobject/event split is a direct fallout of that. :)
> > 
> [ .. ]
> > That way we would get a generic way to request any data from userspace
> > and events that belong to a specific driver or device and not some fake
> > device in the firmware_class.
> > 
> 
> The main problem is that firmware downloading does not fit in well with
> the established functionalities:
> 
> - modprobe returns after the device is fully initialised.
>   -> firmware has to be loaded during modprobe, ie events have to
>      be handled during modprobe

We may come up with a async model for that. Do you have an
requirements/ideas here? I don't have the full picture here.

> - hotplug events are sent when the device registers itself with sysfs
>   -> devices with firmware will then not be fully initialised
>   -> the current hotplug subsystem does not distinguish between
>      states 'device detected' and 'device initialised',
>      so you can't model the firmware behaviour directly onto
>      the linux hotplug subsystem.

If we request the userspace data not to an artificial device, but
instead request that into the module sysfs directory itself, that may
work better?

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel