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

[Greg KH <greg@kroah.com>]

On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote:
> Here is the next revision for udevd:
>   o Small cleanups all over the place.
>   o Swich to the usual linked list format "list.h".
>   o Better timeout handling.
>       We store a timestamp in in every queued event, so we don't wait longer
>       than the timeout specified, if the hole in the list is not shrinking.
>   o ignore udevd target if klibc is used

Nice, I've applied this.

> The code is getting better, but we have still major flaws:
> 
>   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?

>   2. Which sequence is the first one?
>      The automatic exit of the daemon, if we have nothing to do, has the
>      disadvantage of not knowing if the first incoming seqnum is really
>      the first one.
>      So we need to delay the exec of the first exec a small amount of time,
>      to see if we get one with a smaller seqnum  to exec before.
>      Or we simply never exit the daemon, and delay only the very first exec
>      after the start of the daemon.
>      Which way to go?

I don't mind never exiting the daemon, and leaving a small startup delay
at the beginning to make sure we have things in the proper order.  That
way the delay is only once.

>   3. Switch away from ancient ipc to sockets?
>      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?

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