[PATCH] udevd - cleanup and better timeout handling

On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote:
> On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote:
> > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote:
> > > Oh, couldn't resist to try threads.
> > > It's a multithreaded udevd that communicates through a localhost socket.
> > > The message includes a magic with the udev version, so we don't accept
> > > older udevsend's.
> > >
> > > No need for locking, cause we can't bind two sockets on the same address.
> > > The daemon tries to connect and if it fails it starts the daemon.
> > >
> > > We create a thread for every incoming connection, handle over the socket,
> > > sort the messages in the global message queue and exit the thread.
> > > Huh, that was easy with threads :)
> > >
> > > With the addition of a message we wakeup the queue manager thread and
> > > handle timeouts or move the message to the global exec list. This wakes
> > > up the exec list manager who looks if a process is already running for this
> > > device path.
> > > If yes, the exec is delayed otherwise we create a thread that execs udev.
> > > n the background. With the return of udev we free the message and wakeup
> > > the exec list manager to look if something is pending.
> > >
> > > It is just a quick shot, cause I couldn't solve the problems with fork an
> > > scheduling and I wanted to see if I'm to stupid  :)
> > > But if anybody with a better idea or more experience with I/O scheduling
> > > we may go another way. The remaining problem is that klibc doesn't support
> > > threads.
> > >
> > > By now, we don't exec anything, it's just a sleep 3 for every exec,
> > > but you can see the queue management by watching syslog and do:
> > >
> > >   DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc
>
> Next version, switched to unix domain sockets.

Next cleaned up version. Hey, nobody wants to try it :)

Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader
every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3
devices plugged in every second and don't run into any problem but a _very_
big udevd queue.

1 files changed, 13 insertions, 7 deletions

diff --git a/udevd.h b/udevd.h
index 4bccd4b81a..e24bc28a78 100644
--- a/udevd.h
+++ b/udevd.h
@@ -4,6 +4,7 @@
  * Userspace devfs
  *
  * Copyright (C) 2004 Ling, Xiaofeng <xiaofeng.ling@intel.com>
+ * Copyright (C) 2004 Kay Sievers <kay.sievers@vrfy.org>
  *
  *
  *	This program is free software; you can redistribute it and/or modify it
@@ -23,16 +24,21 @@
 
 #include "list.h"
 
-#define FIRST_EVENT_TIMEOUT_SEC		1
-#define EVENT_TIMEOUT_SEC		5
-#define UDEVSEND_RETRY_COUNT		50 /* x 10 millisec */
-
-#define IPC_KEY_ID			1
-#define HOTPLUGMSGTYPE			44
+/*
+ * FIXME: udev_root is post compile configurable and may also be
+ * mounted over at any time and /var/run/ and /tmp/ is unusable,
+ * cause it's cleaned at system startup, long _after_ udevd is
+ * already running. Should we use udev_init_config()?
+ */
 
+#define UDEV_MAGIC			"udev_" UDEV_VERSION
+#define EVENT_TIMEOUT_SEC		5
+#define UDEVSEND_CONNECT_RETRY		20 /* x 100 millisec */
+#define UDEVD_SOCKET			UDEV_ROOT ".udevd.socket"
+#define UDEVD_LOCK			UDEV_ROOT ".udevd.pid"
 
 struct hotplug_msg {
-	long mtype;
+	char magic[20];
 	struct list_head list;
 	pid_t pid;
 	int seqnum;