From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 22 Mar 2005 10:45:08 +0000 Subject: Re: Rework of request firmware Message-Id: <1111488308.6050.24.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 Mon, 2005-03-21 at 22:06 -0500, Jon Smirl wrote: > On Tue, 22 Mar 2005 03:25:05 +0100, Kay Sievers wrote: > > This way we can replay or cancel events at any time if something goes > > wrong. We would get a generic transaction model for the kernel to > > request a configuration action from userspace like copying a firmware > > image, setup a device or run any other userspace helper. > > > > How does that sound? Can this work? > > 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. > 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. > 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. > 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? > 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. 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