Re: Rework of request firmware

[Jon Smirl <jonsmirl@gmail.com>]

On Tue, 22 Mar 2005 11:45:08 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > That's what I was trying to get at. It's the abort of the event that
> > causes problems. The better model is that the event stays active until
> > it is satisfied -- there is no way to automatically abort it. If the
> > event has not been satisfied by module exit time it just gets cleaned
> > up.
> 
> You are lost with that model. How do yo handle more than one device? If
> you have one device already using the module, how do you cancel a
> request for the other one? I don't see how this can work.

There is one active request per device. The events are hung off the
device nodes in sysfs. If a driver needs multiple events per device
they are serialized. This model lets a single driver handle multiple
devices in parallel.

> > It would be convenient to have a sysfs variable on an event like
> > 'replay'. If I set 'replay' to 1 the event will get regenerated to
> > /sbin/hotplug. After I fix things  I could manually retrigger the
> > event and it would run in the hotplug execution environment. You might
> > not even need to be root to trigger a replay.
> 
> I'm more for representing the necessary information with sysfs
> attributes. So userspace can retry to fulfill the request or abort it.
> And the same process that replays the transaction, can trigger the
> requested action or cancel it.

It doesn't matter if the event replay happens from the kernel or a
user space script that picks the info up out of sysfs variables. But I
do think a replay should look just as if /sbin/hotplug were called
again with the same environment/context.

> > Timeout is still useful. Timeout tells the system to generate a user
> > message saying that the device is stuck. But timeout should not abort
> > the event.
> 
> I don't see the need for a timeout. The goal is to get rid of the
> timeouts, right? We never know what time userspace is able to fulfill
> the requests. We just need a way that events don't get lost and let
> userspace handle that at _any_ time it is running again. And timeouts
> that do nothing but send messages are not needed, I think.

Timeout does nothing except generate a hal/dbus event that alerts the
user that manual intervention is required.

> > What about a universal driver model for this? Right now we have
> > probe(). Should we add post()? If post() is null just call probe(). If
> > the driver has a post() function call it instead. The completion event
> > would then call probe(). probe() could still fail and the driver would
> > not be activated.
> 
> As already discussed in earlier mails, I don't see what this will give
> us. Why should we code that into the driver probing? We just need a
> generic userspace transaction a driver can request at any time, right?

probe() returns T/F if the driver can handle the device. For video
cards I need a user space event to complete before I know the answer
T/F.  I have two choices, trigger an async event from probe() and
always return T, or do the event synchronously (like request_firmware)
and deadlock suspend. If I always return T later info from the event
may have made we want to return F.

> > Doing it in the driver layer makes this process standard. Now we can
> > add a uniform device attribute like status. status=offline,
> > status=posting, status=online.
> 
> How does that help? If we get a way to bind and unbind devices from a
> driver through sysfs, why would we need that.
> 
> > You could probably cancel an event. Canceling an event would remove it
> > from sysfs and make sure probe() never gets called. Status would stay
> > at offline. The only way to reactivate the device would be to remove
> > the driver. I don't think we need cancel but if it is there it would
> > be a user controlled action.
> 
> If userspace is not able to fulfill a request it seems logical to be
> able to cancel a transaction. If the requested firmware image file is
> not available, userspace should cancel the request immediately to leave
> the kernel in a clean state and let userspace act on the error.

Say I have a single driver that is controlling two hardware instances.
One instance is working fine. The other gets an event error. If the
event is canceled the only way to get it back is to stop the other
device. Alternatively, if the event just hangs around until module
unload time I can fix it whenever I figure out how to. What does
cancel really gain? The downside is that you can be forced to restart
a working device.

> 
> Thanks,
> Kay
> 

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