Re: Rework of request firmware

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

On Mon, 2005-03-21 at 03:37 +0100, Kay Sievers wrote:
> On Sun, 2005-03-20 at 15:39 -0500, Jon Smirl wrote:
> > On Sun, 20 Mar 2005 21:25:17 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > > Could you please define the requirements for that subsystem _first_ and
> > > make sure that everything we currently know of is covered before adding
> > > stuff to the core. I'm pretty sure that this will have to change several
> > > times before we get that right.
> > 
> > The base device support is missing two things I need:
> > 1) some mechanism to run the POST program

> We want:
> ====
>  o To request data(file) like firmware or setup data from userspace
>    into kernel memory, to use it in the device driver.
>  o To request the execution of a userspace program to setup the device
>    for the kernel while the kernel waits for the program to complete.

Continuing working on the firmware_class requirement definition I
have another idea to check out:

Ben already pointed out the problems with the current firmware loader
during power management state transitions, which causes deadlock
situations with the kernel executed helpers while userspace
is not able to handle that.

What about moving the call_usermodehelper users over to some kind of
kobject_hotplug() call?
We would convert everything to the current hotplug logic and dispatch
all events from here. All events would originate from a sane DEVPATH
and if userspace is running after bootup, it can disable the execution
of /sbin/hotplug and listens for events only on the netlink socket.

If the hotplug handling daemon (a version of udevd already does this)
can not respond to netlink messages, the kernel will queue the events
without any further control needed. If the daemon wakes up again, the
kernel delivers all queued event-packets over the socket.

For the firmware and config-request-events we would need some kind of
async hotplug transaction:
Drivers would request a transaction that must be acknowledged from the
hotplug helper for the driver to continue. For these transactions we
could use a model similar to the current firmware_class.
Every transaction creates a directory in sysfs that contains attributes
with everything needed to handle the request. If userspace has finished
handling the event, it signifies that in with a sysfs attribute and the
driver can continue its work.

This way we can replay or cancel events at any time if something goes
wrong. We would get a generic transaction model for the kernel to
request a configuration action from userspace like copying a firmware
image, setup a device or run any other userspace helper.

How does that sound? Can this work?

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