From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 27 Jan 2004 19:08:09 +0000 Subject: Re: [patch] udevd - cleanup and better timeout handling Message-Id: <20040127190809.GA13461@vrfy.org> 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 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. Kay ------------------------------------------------------- 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