Re: [PATCH] convert udevsend/udevd to using datagram sockets

[Kay Sievers <kay.sievers@vrfy.org>]

On Wed, Feb 04, 2004 at 02:00:35AM -0500, Chris Friesen wrote:
> This patch does a couple of things to udevsend/udevd.  It doesn't touch
> udev itself at all.
> 
> 1) It switches to using the abstract namespace.  This simplifies things
> since you don't have to go around unlinking.  When the socket goes away,
> the address is gone.

This is really nice, I like it. Didn't know that this is possible.

Do you have any idea what we can do with the lock file. It would be very
nice to get rid of it, cause we remount the filesystem and it's gone.

> 2) The protocol between udevsend and udevd is fundamentally
> message-based.  This patch recognizes this by using SOCK_DGRAM rather
> than SOCK_STREAM, which simplifies the message protocol.  (Note that
> with unix sockets, you can still detect if the daemon is not running
> with SOCK_DGRAM. )
> 
> 3) The main loop in udevd is much simplified.  Part of this is due to
> the lower complexity of datagram sockets.  As well, the new main loop
> just calls a plain function that sits on a blocking recv() to handle
> incoming messages instead of spawning a thread that does almost nothing
> and then exits.

You are talking about complexity, but what is about speed?

blocking daemon:
  time for i in `seq 1 100`; do SEQNUM=$i ACTION­d DEVPATH=$i ./udevsend x; done
  real    0m1.175s
  user    0m0.054s
  sys     0m0.081s

threading daemon:
  time for i in `seq 1 100`; do SEQNUM=$i ACTION­d DEVPATH=$i ./udevsend x; done
  real    0m0.048s
  user    0m0.018s
  sys     0m0.029s

I don't see what we get with the blocking I/O. It seems more like
personal taste than numbers. :)
You may catch up with NPTL and old thread issues.
Linux is _now_ really really nice with threads.


> There is still a hole if the message gets delivered and the server
> crashes before it gets handled--to close that we would need an ack
> message.  If anyone wants us to be that paranoid, it would be easy to
> implement.

Uhh, first switch to unreliable communication and the make a protocol by
yourself? Sounds a bit crazy.

> Any comments?

I can see your motivation, but unless we can get rid of _all_ the threads
or at least getting faster, I don't want to change it.

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