Re: Rework of request firmware

[Jon Smirl <jonsmirl@gmail.com>]

On Sun, 20 Mar 2005 20:27:24 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> But if the config event does not know how to fulfill the request, it may
> cancel the operation by triggering the sysfs attribute. And that will
> lead to a failing device initialization which is an event that userspace
> is interested in.
> Again, the way such errors are send to userspace in a sane way, needs to
> be solved for this to happen ...

I was going to remove the cancel operation. Userspace would only be
able to signal: completed or restart.

Status and user_data would be permanent attributes on the device. I
added a field to 'struct device' to track the progress of the loading.
If the driver is removed and there is a pending kernel thread waiting,
the device layer has enough info to get rid of it.

status=0 offline
status=1 on-line
status=2 waiting for user space action
status=3 user action complete

Setting status=2 would clear the data and get ready to receive new data
Setting  status=3 indicates that load/action is complete.
User space can't set states 0/1

A timeout would leave everything as is, but generate a user readable
message to fix things.
Exiting the module would remove all pending threads, cleanup, and set status=0.

Userspace could possibly set a state=4 which would reset the data load
and regenerate the event. All that need to be remember is the
environment variable string.


-- 
Jon Smirl
jonsmirl@gmail.com


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