From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Mon, 21 Mar 2005 02:37:00 +0000 Subject: Re: Rework of request firmware Message-Id: <1111372620.23995.202.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 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 I've put that on the list below. > 2) subdirectories under class_device for hotplug monitors Childs of class devices is somewhere on Greg's list, I think. :) Don't know how close we are to allow that. Greg? > I don't know enough about the details of how the hotplug subsystem > works, plus I have a lot of work I still need to do the framebuffer > subsystem. I'll work around these items until a fix is in place. 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. We currently have: ========= o call_usermodehelper() o request_firmware() o kobject_hotplug() executes /sbin/hotplug Current problems: ======== o call_usermodehelper will not work if userspace is not ready to fulfill the request at bootup or we are in suspend/resume. o Same for request_firmware, it has a async version nobody uses, but it may be good starting point. I have seen several oops's of request_firmware if the timeout tries to cancel the request. o Both versions can not be replayed without the content of the original hotplug environment. o If a request fails and the module can not be removed, how can we probe the device again? Requirements: ====== o Provide core functionality to request a userspace action for a specific device. o The events should be send through /sbin/hotplug and we get the netlink events along with the same call. o The request should be able to wait as long as the system/userspace needs to fulfill the request or actively cancels it. o It should be possible to fulfill the request later, without the hotplug environment available. o userspace should be notified about any failing operation to react accordingly. o Be able to request more than one action for a single device: one after the other or in parallel, but with its current state visible to userspace. o We need a way to let /sbin/hotplug recognize the kind of event, to avoid running an agent for every device. Questions: ===== o How do we reprobe a device if we can't unload the module? o From which DEVPATH should the requests originate from? The module itself in sysfs, the physical device, the class device? Or stick with with our own temporary class device for the requests? o Do we need any timeout? If yes, how is that to be handled? o Will all users/probers be able to schedule its work until the request comes back from userspace? Possible implementations: ============1. We keep the current class_device logic for loading firmware but switch everything over to the async version without the timeout. And we add new functionality for the configuration requests. 2. Drivers they want to emit requests create attributes in the devices sysfs representation and send out hotplug events with a specific action. 3. We add a child for every request below the device that requests the actual action. This child device has the attributes to control the request. Any ideas? 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