Re: Rework of request firmware

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

On Sun, 2005-03-20 at 14:50 -0500, Jon Smirl wrote:
> 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.

If I don't have the requested data to copy to the driver. What should I
do?

> Status and user_data would be permanent attributes on the device.

If the driver needs 2 requests to set up and something goes wrong: Which
one should I load into the attribute now? I'm lost lost with that
layout.

> I added a field to 'struct device' to track the progress of the loading.

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.

> If the driver is removed and there is a pending kernel thread waiting,
> the device layer has enough info to get rid of it.

How do you remove the busy driver?

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

Why should we do that? If userspace can not fulfill the request, why
should we keep the kernel state around?

> Exiting the module would remove all pending threads, cleanup, and set status=0.

Yeah, sounds very much like the current oops'ing firmware_class. :)

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

That's the problem. Who remembers what?

How do we handle devices which are not fully registered until they got
the request handled successfully?

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