Re: Firmware class breaks udev

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

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

> The current implementation of the firmware class breaks a fundamental
> assumption in udev: that the physical device can be initialised fully
> prior to executing the next event for that device.
> 
> As the firmware is indeed _required_ to initialise the device we wait
> until the timeout is triggered and the try to execute the fimware event,
> which of course will fail.
> 
> 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.

> 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.

> 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. 

> 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. :)

I'm thinking of providing a function that adds a single file to a
kobject in sysfs. That file may be named after the data it expects. We
would send out a KOBJ_REQUEST_DATA hotplug event for that kobject and
userspace can copy any data to that file.
If possible, the sysfs data file should use the default fs_operations,
which will give us a ramfs based file and not the current vmalloc() hack
and the "finished loading" attribute. And we would get the release()
call if userspace closes the file, so there is no need for the loading
attribute.
A good place for drivers to create such a file may be the module that
requests data in the /sys/module/* directory.

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 power management guys talked about the need for a mandatory async
model for firmware loading:
  http://lists.osdl.org/pipermail/linux-pm/2004-November/000147.html

And I still need to understand the whole picture before I can start
working on it. Any ideas?

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