From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sun, 20 Mar 2005 13:37:16 +0000 Subject: Re: Rework of request firmware Message-Id: <1111325836.21516.40.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 Sat, 2005-03-19 at 23:06 -0500, Jon Smirl wrote: > On Sat, 26 Feb 2005 20:41:16 +0100, Kay Sievers 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_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