From 53921bfa44129a19661a4aaa4c1647282921fc18 Mon Sep 17 00:00:00 2001 From: "kay.sievers@vrfy.org" Date: Sun, 1 Feb 2004 09:12:36 -0800 Subject: [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. --- udevd.h | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) (limited to 'udevd.h') 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 + * Copyright (C) 2004 Kay Sievers * * * 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; -- cgit v1.2.3-54-g00ecf