From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Wed, 04 Feb 2004 14:02:52 +0000 Subject: Re: [PATCH] convert udevsend/udevd to using datagram sockets Message-Id: <20040204140252.GA32490@vrfy.org> List-Id: References: <40209893.8080109@sympatico.ca> In-Reply-To: <40209893.8080109@sympatico.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.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. >=20 > 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. ) >=20 > 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=3D$i ACTION=ADd DEVPATH=3D$i ./udevs= end x; done real 0m1.175s user 0m0.054s sys 0m0.081s threading daemon: time for i in `seq 1 100`; do SEQNUM=3D$i ACTION=ADd DEVPATH=3D$i ./udevs= end 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