mirror of
https://github.com/AuxXxilium/eudev.git
synced 2024-12-15 02:56:51 +07:00
53921bfa44
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.
50 lines
1.5 KiB
C
50 lines
1.5 KiB
C
/*
|
|
* udevd.h
|
|
*
|
|
* 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
|
|
* under the terms of the GNU General Public License as published by the
|
|
* Free Software Foundation version 2 of the License.
|
|
*
|
|
* This program is distributed in the hope that it will be useful, but
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
* General Public License for more details.
|
|
*
|
|
* You should have received a copy of the GNU General Public License along
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
* 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
*
|
|
*/
|
|
|
|
#include "list.h"
|
|
|
|
/*
|
|
* 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 {
|
|
char magic[20];
|
|
struct list_head list;
|
|
pid_t pid;
|
|
int seqnum;
|
|
time_t queue_time;
|
|
char action[8];
|
|
char devpath[128];
|
|
char subsystem[16];
|
|
};
|