Re: Firmware class breaks udev

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

On Wed, 2005-03-16 at 10:52 -0500, Jon Smirl wrote:
> On Wed, 16 Mar 2005 08:27:38 +0100, Hannes Reinecke <hare@suse.de> wrote:
> > Greg KH wrote:
> > > On Tue, Mar 15, 2005 at 02:09:17PM +0100, Hannes Reinecke wrote:
> > [ .. ]
> > >>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
> > >
> > > That can be changed, modprobe can return before the device is
> > > initialized.  I can change the driver to do this, if you wish.
> > >
> > Oh, that would be good.
> > We should fix the firmware_class / any firmware-dependend device to
> > return (ie finish their probing) when the firmware device has been
> > registered in sysfs.
> > Then we have a chance to handle the firmware event, and on succesful
> > downloading the proper device will appear in sysfs. Something like
> > - handling pci event
> >   -> modprobe <corresponding module>
> >      -> generates firmware event
> >      -> returns
> >   -> event handling done
> > - handling firmware event
> >   -> download firmware
> >   -> device initialisation
> >      -> device_register()
> >         -> generate class device event
> > - handling class device event
> 
> Wouldn't the cleanest way to handle this be to have a pre-probe call
> to the device structure?

For what other than requesting data from userspace would we need this?

> In pre-probe you would trigger the
> request_initialization_nowait(). Then when user space indicates that
> it is done it pokes a sysfs attribute. poking the attrib then causes
> the normal probe() function to be called. If pre-probe() is null then
> skip all this and call probe().

If we get something like a request_user_data() that works
asynchronously, and a driver that need that functionality can just call
it, wouldn't it be sufficient?

> I'd like to rename everthing request_initialization instead of
> firmware. I'd also like to hang the firmware sysfs directory off from
> each device node as it is requested instead of having a firmware
> subsys. That gets rid of the name conflicts.

The class_firmware should go. Definitely! But we better add something
new and don't rename that thing. It will be a lot different from the
current stuff, I expect. And we can move the users of the firmware_class
over one by one before we decide remove it.

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