From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sun, 20 Mar 2005 20:25:17 +0000 Subject: Re: Rework of request firmware Message-Id: <1111350317.23995.83.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 Sun, 2005-03-20 at 14:50 -0500, Jon Smirl wrote: > On Sun, 20 Mar 2005 20:27:24 +0100, Kay Sievers 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_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