Re: Rework of request firmware

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

On Sat, 2005-03-19 at 23:06 -0500, Jon Smirl wrote:
> On Sat, 26 Feb 2005 20:41:16 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > I think the request_firmware() should be redesigned in a generic
> > request_user_data(kobj) call. This event would copy arbitrary data into
> > a sysfs file and something like KOBJ_REQUEST_DATA would do it.
> > 
> > The call should create a file inside of a existing device and the event
> > handler should copy the data into this file instead of creating a own
> > class device for the firmware as we do today.
> 
> This is a rework of request firmware to move the attributes from their
> own class into the device sysfs directory.

I don't think that we should change firmware_class that way. If we want
to have something that acts like this, we should provide a new interface
and not rename and change something that is widely used, seems to work
but has races and easy to trigger oops's. 

> I am also generalizing
> things so that I can request a post (this is what I need) as well as
> firmware. This is a first post of the code, please tell me what I can
> do to improve it before I send it to lkml.

What is the concept of a "post"? Does it receive data for the kernel to
use? What is the overlap with firmware loading here? You just need to
run a program from userspace, right? 

> I made a few changes in the base code:
> 1) I modified kobj_hotplug() to take an extra function for adding
> variables. This lets the event add the normal variable for the kset
> and then I can tack mine on too.
> 2) New event KOBJ_POST. $POST and $FIRMWARE are used to differentiate
> post versus firmware load in the script. Should this be two events
> instead?

Please explain what kind of event "post" is. Is it more than a
configuration-request that executes a userspace helper for a specific
device?

> 3) The script now needs to be in
> /etc/hotplug.d/default/30-post.hotplug. firmware.agent isn't used
> anymore. The firmware doesn't need to change or move.
> 4) I added a pointer to 'struct device' to track the firmware in
> sysfs. Is there a better way to do this?
> 5) I added the time out to /sys/firmware/post_timeout since there is
> no /sys/class/firmware any more.

Hmm, that place seems not in charge of this kind of "firmware", right?

> 6) How should everything be named? firmware, post, initialization, etc??
> 7) Should request_firmware() be deprecated forcing the move to
> request_firmware_nowait?

I still would like to see clearly defined list of requirements for:
  o async userspace data-requests into the kernel
  o async userspace configuration-requests from the kernel

before we start hacking on it. The current request_firmware() is a
not-so-nice example for doing it that way. All that stuff needs to play
with hotplug, initramfs/bootup, suspend/resume. And we should come up
with something that fits _all_ the needs and move the current
request_firmware-users over to 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