From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Mon, 26 Jan 2004 19:11:10 +0000 Subject: Re: [patch] udevd - cleanup and better timeout handling Message-Id: <20040126191110.GA10913@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 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. Is it feasible to run in parallel for different paths, or can you think of any problem? > > We may want threads for this, but klibc doesn't support it. > > Nevermind, the ipc stuff is also not supported :) > > Any idea? > > Heh, I can easily add the ipc stuff to klibc. > I'm not a experienced enough userspace programmer to discuss the merits > of either option here. Anyone else? IPC is from the 70's :) It's not refcounted so we may leave messages in the kernel without any process using it. Sockets are nicer, we easily recognize, if the daemon isn't running. But we need threads for this to implement it without doing things like I/O multiplex or use of shared memory, cause all tasks need to work on the same global queue. So if we can get threads in klibc, I would prefer to switch to sockets. IPC isn't really a option for a todays program, but it works for us and sockets don't solve any big problem we have. thanks, 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