From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 22 Mar 2005 02:25:05 +0000 Subject: Re: Rework of request firmware Message-Id: <1111458305.4075.50.camel@localhost.localdomain> List-Id: References: <9e473391050319200625032789@mail.gmail.com> In-Reply-To: <9e473391050319200625032789@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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 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_id396&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