From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Tue, 27 Jan 2004 19:13:09 +0000 Subject: Re: [patch] udevd - cleanup and better timeout handling Message-Id: <20040127191309.GA26587@kroah.com> List-Id: References: <20040125200314.GA8376@vrfy.org> In-Reply-To: <20040125200314.GA8376@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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