Re: Rework of request firmware

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

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

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_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