Re: [patch] udevd - cleanup and better timeout handling

[Greg KH <greg@kroah.com>]

On Tue, Jan 27, 2004 at 08:08:09PM +0100, Kay Sievers wrote:
> On Tue, Jan 27, 2004 at 07:56:04AM +0100, Kay Sievers wrote:
> > On Mon, Jan 26, 2004 at 11:28:19AM -0800, Greg KH wrote:
> > > On Mon, Jan 26, 2004 at 08:11:10PM +0100, Kay Sievers wrote:
> > > > On Mon, Jan 26, 2004 at 10:22:34AM -0800, Greg KH wrote:
> > > > > On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote:
> > > > > >   1. We are much too slow.
> > > > > >      We want to exec the  real udev in the background, but a 'remove'
> > > > > >      is much much faster than a 'add', so we have a problem.
> > > > > >      Question: is it neccessary to order events for different devpath's?
> > > > > >      If no, we may wait_pid() for the exec only if we have another udev
> > > > > >      working on the same devpath.
> > > > > 
> > > > > But how will we keep track of that?  It's probably easier just to wait
> > > > > for each one to finish, right?
> > > > 
> > > > We leave the message in the queue until we reach the SIGCHLD for this
> > > > pid. So we can search the queue if we are already working on this devpath,
> > > > and delay the new exec until the former exec comes back.
> > > 
> > > Ok, if that isn't too much trouble.
> > > 
> > > > Is it feasible to run in parallel for different paths, or can you think
> > > > of any problem?
> > > 
> > > I can't think of any problem with that.
> > 
> > Here is the next round. We have three queues now. All incoming messages
> > are queued in msg_list and if nothing is missing we move it to the
> > running_list and exec in the background.
> > If the exec comes back, it removes the message from the running_list and
> > frees the message.
> > 
> > Before we exec, we check the running_list if there is a udev running on
> > the same device path. If yes, we move the message to the delay_list. If
> > the former exec comes back, we move the message to the running_list and
> > exec it.
> 
> Oh, sorry forget about it now.
> I will come up with something better tested.

Oops, I just applied this version :)

I'll try testing this later on today.

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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