udevd - cleanup and better timeout handling
PATCH 1/1 udevd - cleanup and better timeout handling
Here is the next revision for udevd:
o Small cleanups all over the place.
o Swich to the usual linked list format "list.h".
o Better timeout handling.
We store a timestamp in in every queued event, so we don't wait longer than the timeout specified, if the hole in the list is not shrinking.
o ignore udevd target if klibc is used
The code is getting better, but we have still major flaws:
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we may wait_pid() for the exec only if we have another udev working on the same devpath.
2. Which sequence is the first one?
The automatic exit of the daemon, if we have nothing to do, has the disadvantage of not knowing if the first incoming seqnum is really the first one.
So we need to delay the exec of the first exec a small amount of time, to see if we get one with a smaller seqnum to exec before. Or we simply never exit the daemon, and delay only the very first exec after the start of the daemon.
Which way to go?
3. Switch away from ancient ipc to sockets?
We may want threads for this, but klibc doesn't support it. Nevermind, the ipc stuff is also not supported :) Any idea?
thanks,
Kay
Makefile +5 -3
@@ -147,17 +147,19 @@ -D__KLIBC__ -fno-builtin-printf LIB_OBJS = LDFLAGS = --static --nostdlib -nostartfiles -nodefaultlibs + UDEVD = else CRT0 = LIBC = CFLAGS += -I$(GCCINCDIR) LIB_OBJS = -lc LDFLAGS = + UDEVD = $(DAEMON) $(SENDER) endif CFLAGS += -I$(PWD)/libsysfs -all: $(ROOT) $(DAEMON) $(SENDER) +all: $(ROOT) $(UDEVD) @extras="$(EXTRAS)" ; for target in $$extras ; do \ echo $$target ; \ $(MAKE) prefix=$(prefix) LD="$(LD)" SYSFS="$(SYSFS)" \
@@ -231,11 +233,11 @@ $(LD) $(LDFLAGS) -o $(ROOT) $(CRT0) $(OBJS) $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $(ROOT) -$(DAEMON): $(ROOT) udevd.h udevd.o +$(DAEMON): udevd.h udevd.o udevd.o logging.o $(LD) $(LDFLAGS) -o $(DAEMON) $(CRT0) udevd.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $(ROOT) -$(SENDER): $(ROOT) udevd.h udevsend.o +$(SENDER): udevd.h udevsend.o udevd.o logging.o $(LD) $(LDFLAGS) -o $(SENDER) $(CRT0) udevsend.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $(ROOT)
udevd.c +112 -119
356 lines not on this page · raw message
udevd.h +10 -5
@@ -21,17 +21,22 @@* */ -#define DEFAULT_UDEV_EXEC "./udev" -#define DEFAULT_UDEVD_EXEC "./udevd" +#include "list.h" -#define IPC_KEY_ID 0 -#define HOTPLUGMSGTYPE 44 +#define UDEV_EXEC "./udev" +#define UDEVD_EXEC "./udevd" +#define UDEVD_TIMEOUT_SECONDS 60 +#define EVENT_TIMEOUT_SECONDS 5 + +#define IPC_KEY_ID 0 +#define HOTPLUGMSGTYPE 44struct hotplug_msg {long mtype; -struct hotplug_msg *next; +struct list_head list;int seqnum; +time_t queue_time;char action[8 ];char devpath[128 ];char subsystem[16 ];
udevsend.c +6 -4
@@ -64,6 +64,7 @@static int build_hotplugmsg (struct hotplug_msg *msg,char *action,char *devpath,char *subsystem,int seqnum) { +memset (msg,0x00 ,sizeof (msg)); msg->mtype =HOTPLUGMSGTYPE ; msg->seqnum = seqnum;strncpy (msg->action, action,8 );
@@ -85,7 +86,8 @@switch (child_pid) {case 0 :/* daemon */ -execl (DEFAULT_UDEVD_EXEC ,NULL ); +setsid (); +execl (UDEVD_EXEC ,"udevd" ,NULL );dbg ("exec of daemon failed" );exit (1 );case -1 :
@@ -99,7 +101,7 @@dbg ("fork of helper failed" );return -1 ;default : -wait (0 ); +wait (NULL ); }return 0 ; }
@@ -147,7 +149,7 @@ seq =atoi (seqnum);/* create ipc message queue or get id of our existing one */ - key =ftok (DEFAULT_UDEVD_EXEC ,IPC_KEY_ID ); + key =ftok (UDEVD_EXEC ,IPC_KEY_ID ); size =build_hotplugmsg (&message, action, devpath, subsystem, seq); msgid =msgget (key,IPC_CREAT );if (msgid ==-1 ) {
@@ -165,7 +167,7 @@/* get state of ipc queue */ tspec.tv_sec =0 ; tspec.tv_nsec =10000000 ;/* 10 millisec */ - loop =20 ; + loop =30 ;while (loop--) { retval =msgctl (msgid,IPC_STAT , &msg_queue);if (retval ==-1 ) {
Quoted 7 lines · Kay Sievers
Here is the next revision for udevd:
o Small cleanups all over the place.
o Swich to the usual linked list format "list.h".
o Better timeout handling.
We store a timestamp in in every queued event, so we don't wait longer than the timeout specified, if the hole in the list is not shrinking.
o ignore udevd target if klibc is used
Nice, I've applied this.
Quoted 8 lines
The code is getting better, but we have still major flaws:
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
Quoted 9 lines
2. Which sequence is the first one?
The automatic exit of the daemon, if we have nothing to do, has the disadvantage of not knowing if the first incoming seqnum is really the first one.
So we need to delay the exec of the first exec a small amount of time, to see if we get one with a smaller seqnum to exec before. Or we simply never exit the daemon, and delay only the very first exec after the start of the daemon.
Which way to go?
I don't mind never exiting the daemon, and leaving a small startup delay at the beginning to make sure we have things in the proper order. That way the delay is only once.
Quoted 4 lines
3. Switch away from ancient ipc to sockets?
We may want threads for this, but klibc doesn't support it. Nevermind, the ipc stuff is also not supported :) Any idea?
Heh, I can easily add the ipc stuff to klibc.
I'm not a experienced enough userspace programmer to discuss the merits of either option here. Anyone else?
thanks,
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Is it feasible to run in parallel for different paths, or can you think of any problem?
Quoted 7 lines
Quoted 3 lines
We may want threads for this, but klibc doesn't support it. Nevermind, the ipc stuff is also not supported :) Any idea?
Heh, I can easily add the ipc stuff to klibc.
I'm not a experienced enough userspace programmer to discuss the merits of either option here. Anyone else?
IPC is from the 70's :) It's not refcounted so we may leave messages in the kernel without any process using it. Sockets are nicer, we easily recognize, if the daemon isn't running. But we need threads for this to implement it without doing things like I/O multiplex or use of shared memory, cause all tasks need to work on the same global queue.
So if we can get threads in klibc, I would prefer to switch to sockets. IPC isn't really a option for a todays program, but it works for us and sockets don't solve any big problem we have.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.
Quoted 6 lines
Quoted 2 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
I can't think of any problem with that.
Quoted 14 lines
Quoted 7 lines
Quoted 3 lines
We may want threads for this, but klibc doesn't support it. Nevermind, the ipc stuff is also not supported :) Any idea?
Heh, I can easily add the ipc stuff to klibc.
I'm not a experienced enough userspace programmer to discuss the merits of either option here. Anyone else?IPC is from the 70's :) It's not refcounted so we may leave messages in the kernel without any process using it. Sockets are nicer, we easily recognize, if the daemon isn't running. But we need threads for this to implement it without doing things like I/O multiplex or use of shared memory, cause all tasks need to work on the same global queue.
Quoted 3 lines
So if we can get threads in klibc, I would prefer to switch to sockets. IPC isn't really a option for a todays program, but it works for us and sockets don't solve any big problem we have.
Where would we need threads to do this? In udevsend? Can't we just send the message to the socket and forget about it there?
In udevd can't we just read the socket if any data is available?
I really, really want to stay away from threads.
No, I do not think klibc will ever support them, and state machines are much nicer than multi threaded apps (for the most part.)
If sockets don't really help much, I'll go add support to klibc for ipc...
thanks,
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Greg KH
Quoted 6 lines · Kay Sievers
Quoted 1 line · Greg KH
On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote:
So if we can get threads in klibc, I would prefer to switch to sockets. IPC isn't really a option for a todays program, but it works for us and sockets don't solve any big problem we have.
Where would we need threads to do this? In udevsend? Can't we just send the message to the socket and forget about it there?
udevd need to be able to talk to multiple senders at the same time. Otherwise a simple connect from a client blocks the whole process. You may use select() for this and multiplex the connections, or fork a child and maintain the queue in shared memory. But that's all not really nice. I think threads are the nicest option, if you want sockets.
Quoted 1 line
In udevd can't we just read the socket if any data is available?
No, it blocks, until the client sends, or we need to poll.
Quoted 2 lines
No, I do not think klibc will ever support them, and state machines are much nicer than multi threaded apps (for the most part.)
What kind of state machine you are thinking of?
How does it handle multiple client sockets. Do you mean a scheduler?
Quoted 1 line
If sockets don't really help much, I'll go add support to klibc for ipc...
I'm fine with it.
We cant do it later if we want, when all the other problems are solved :)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Kay Sievers
Quoted 4 lines · Greg KH
Quoted 3 lines · Kay Sievers
Quoted 1 line · Greg KH
On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote:
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
So if we can get threads in klibc, I would prefer to switch to sockets. IPC isn't really a option for a todays program, but it works for us and sockets don't solve any big problem we have.
Where would we need threads to do this? In udevsend? Can't we just send the message to the socket and forget about it there?
udevd need to be able to talk to multiple senders at the same time.
Hm, we can't use the same socket? I need to read up on how that all works...
Quoted 5 lines
Otherwise a simple connect from a client blocks the whole process.
You may use
select()for this and multiplex the connections, or fork a child and maintain the queue in shared memory. But that's all not really nice. I think threads are the nicest option, if you want sockets.
Ok, I'll trust you here :)
Quoted 3 lines
Quoted 1 line
In udevd can't we just read the socket if any data is available?
No, it blocks, until the client sends, or we need to poll.
Even if you accept on a socket that has O_NONBLOCK set on it?
Quoted 5 lines
Quoted 2 lines
No, I do not think klibc will ever support them, and state machines are much nicer than multi threaded apps (for the most part.)
What kind of state machine you are thinking of?
How does it handle multiple client sockets. Do you mean a scheduler?
Hm, I don't know what kind of state machine I'm thinking of, usually you can easily replace a program that has a lot of threads with a single one using a state machine. But I've also written stuff that can't be done that way (accepting serial data from one thread, etc.)
Quoted 4 lines
Quoted 1 line
If sockets don't really help much, I'll go add support to klibc for ipc...
I'm fine with it.
We cant do it later if we want, when all the other problems are solved :)
That sounds fine with me :)
thanks,
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
Quoted 1 line · Greg KH
On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote:
So if we can get threads in klibc, I would prefer to switch to sockets. IPC isn't really a option for a todays program, but it works for us and sockets don't solve any big problem we have.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Where would we need threads to do this? In udevsend? Can't we just send the message to the socket and forget about it there?
udevd need to be able to talk to multiple senders at the same time.
Hm, we can't use the same socket? I need to read up on how that all works...
You bind() one and then listen() on it. If one connect() to it, you accept() and use this file descriptor to communicate and bind and listen on a new one.
So now you have the problem:
You have multiple sockets open and must handle it all at once. You have the option of nonblocking I/O with stupid polling or better with select() which notifies you if a socket has data for you.
Or the forking of childs, each child takes the accepted socket and the parent opens a new one. If we fork for every new connection, we lose the queue and need shared memory, other ipc, pipes or files...
But the problem is getting more complex if you want to do other thing at the same time like exec a list of udevs in the background and handle timeouts...
This is all possible with a single process, but I don't want to debug such a beast.
All problems magically go away with threads, cause we share the same address space and let the kernel schedule our tasks.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 17 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.Quoted 6 lines
Quoted 2 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Quoted 6 lines
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
I can't think of any problem with that.
Here is the next round. We have three queues now. All incoming messages are queued in msg_list and if nothing is missing we move it to the running_list and exec in the background.
If the exec comes back, it removes the message from the running_list and frees the message.
Before we exec, we check the running_list if there is a udev running on the same device path. If yes, we move the message to the delay_list. If the former exec comes back, we move the message to the running_list and exec it.
The very first event is delayed now to catch possible earlier sequences, every following event is executed without delay if no sequence is missing.
The daemon doesn't exit by itself any longer, cause we don't want to delay every first exec.
I've put a $(PWD) for now in the Makefile for testing this beast. Only the local binaries are executed, not the /sbin/udev. We can change it if we are ready for real testing.
And SIGKILL can't be cought, so I removed it from the handler :)
thanks,
Kay
06:58:36 sig_handler: caught signal 15
06:58:36 main: using ipc queue 0x2d548
06:58:37 message is still in the ipc queue, starting daemon... 06:58:37 work: received sequence 3, expected sequence 0
06:58:37 msg_dump_queue: sequence 3 in queue
06:58:37 set_timeout: set timeout in 1 seconds
06:58:37 main: using ipc queue 0x2d548
06:58:37 main: using ipc queue 0x2d548
06:58:37 work: received sequence 1, expected sequence 1
06:58:37 msg_dump_queue: sequence 1 in queue
06:58:37 msg_dump_queue: sequence 3 in queue
06:58:37 msg_dump: sequence 1, 'add', '/block/sda', 'block'
06:58:37 msg_exec: child [8038] created
06:58:37 running_moveto_queue: move sequence 1 [8038] to running queue '/block/sda' 06:58:37 set_timeout: set timeout in 5 seconds
06:58:37 work: received sequence 2, expected sequence 2
06:58:37 msg_dump_queue: sequence 2 in queue
06:58:37 msg_dump_queue: sequence 3 in queue
06:58:37 msg_dump: sequence 2, 'add', '/block/sdb', 'block'
06:58:37 msg_exec: child [8039] created
06:58:37 running_moveto_queue: move sequence 2 [8039] to running queue '/block/sdb' 06:58:37 msg_dump: sequence 3, 'add', '/block/sdc', 'block'
06:58:37 msg_exec: child [8040] created
06:58:37 running_moveto_queue: move sequence 3 [8040] to running queue '/block/sdc' 06:58:37 main: using ipc queue 0x2d548
06:58:37 main: using ipc queue 0x2d548
06:58:37 work: received sequence 4, expected sequence 4
06:58:37 msg_dump_queue: sequence 4 in queue
06:58:37 msg_dump: sequence 4, 'remove', '/block/sdc', 'block' 06:58:37 msg_exec: delay exec of sequence 4, [8040] already working on '/block/sdc' 06:58:37 delayed_moveto_queue: move event to delayed queue '/block/sdc' 06:58:37 msg_exec: child [8043] created
06:58:37 running_moveto_queue: move sequence 4 [8043] to running queue '/block/sdc' 06:58:37 work: received sequence 5, expected sequence 5
06:58:37 msg_dump_queue: sequence 5 in queue
06:58:37 msg_dump: sequence 5, 'remove', '/block/sdb', 'block' 06:58:37 msg_exec: delay exec of sequence 5, [8039] already working on '/block/sdb' 06:58:37 delayed_moveto_queue: move event to delayed queue '/block/sdb' 06:58:37 msg_exec: child [8044] created
06:58:37 running_moveto_queue: move sequence 5 [8044] to running queue '/block/sdb' 06:58:37 main: using ipc queue 0x2d548
06:58:37 main: using ipc queue 0x2d548
06:58:37 work: received sequence 8, expected sequence 6
06:58:37 msg_dump_queue: sequence 8 in queue
06:58:37 set_timeout: set timeout in 5 seconds
06:58:37 work: received sequence 6, expected sequence 6
06:58:37 msg_dump_queue: sequence 6 in queue
06:58:37 msg_dump_queue: sequence 8 in queue
06:58:37 msg_dump: sequence 6, 'remove', '/block/sda', 'block' 06:58:37 msg_exec: delay exec of sequence 6, [8038] already working on '/block/sda' 06:58:37 delayed_moveto_queue: move event to delayed queue '/block/sda' 06:58:37 msg_exec: child [8047] created
06:58:37 running_moveto_queue: move sequence 6 [8047] to running queue '/block/sda' 06:58:37 set_timeout: set timeout in 5 seconds
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8038
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8039
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8040
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8043
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8044
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:38 sig_handler: caught signal 17
06:58:38 sig_handler: exec finished, pid 8047
06:58:38 set_timeout: set timeout in 4 seconds
06:58:38 msg_dump_queue: sequence 8 in queue
06:58:39 main: using ipc queue 0x2d548
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 9, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 work: received sequence 11, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 10, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 10 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 13, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 10 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 msg_dump_queue: sequence 13 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 14, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 10 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 msg_dump_queue: sequence 13 in queue
06:58:39 msg_dump_queue: sequence 14 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:39 main: using ipc queue 0x2d548
06:58:39 work: received sequence 15, expected sequence 7
06:58:39 msg_dump_queue: sequence 8 in queue
06:58:39 msg_dump_queue: sequence 9 in queue
06:58:39 msg_dump_queue: sequence 10 in queue
06:58:39 msg_dump_queue: sequence 11 in queue
06:58:39 msg_dump_queue: sequence 13 in queue
06:58:39 msg_dump_queue: sequence 14 in queue
06:58:39 msg_dump_queue: sequence 15 in queue
06:58:39 set_timeout: set timeout in 3 seconds
06:58:41 main: using ipc queue 0x2d548
06:58:41 work: received sequence 12, expected sequence 7
06:58:41 msg_dump_queue: sequence 8 in queue
06:58:41 msg_dump_queue: sequence 9 in queue
06:58:41 msg_dump_queue: sequence 10 in queue
06:58:41 msg_dump_queue: sequence 11 in queue
06:58:41 msg_dump_queue: sequence 12 in queue
06:58:41 msg_dump_queue: sequence 13 in queue
06:58:41 msg_dump_queue: sequence 14 in queue
06:58:41 msg_dump_queue: sequence 15 in queue
06:58:41 set_timeout: set timeout in 1 seconds
06:58:42 sig_handler: caught signal 14
06:58:42 sig_handler: event timeout reached
06:58:42 event 8, age 5 seconds, skip event 7-7
06:58:42 msg_dump: sequence 8, 'add', '/block/sdb', 'block'
06:58:42 msg_exec: child [8057] created
06:58:42 running_moveto_queue: move sequence 8 [8057] to running queue '/block/sdb' 06:58:42 msg_dump: sequence 9, 'add', '/block/sdc', 'block'
06:58:42 msg_exec: child [8058] created
06:58:42 running_moveto_queue: move sequence 9 [8058] to running queue '/block/sdc' 06:58:42 msg_dump: sequence 10, 'remove', '/block/sdc', 'block' 06:58:42 msg_exec: delay exec of sequence 10, [8058] already working on '/block/sdc' 06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sdc' 06:58:42 msg_exec: child [8059] created
06:58:42 running_moveto_queue: move sequence 10 [8059] to running queue '/block/sdc' 06:58:42 msg_dump: sequence 11, 'remove', '/block/sdb', 'block' 06:58:42 msg_exec: delay exec of sequence 11, [8057] already working on '/block/sdb' 06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sdb' 06:58:42 msg_exec: child [8060] created
06:58:42 running_moveto_queue: move sequence 11 [8060] to running queue '/block/sdb' 06:58:42 msg_dump: sequence 12, 'remove', '/block/sda', 'block' 06:58:42 msg_exec: child [8061] created
06:58:42 running_moveto_queue: move sequence 12 [8061] to running queue '/block/sda' 06:58:42 msg_dump: sequence 13, 'add', '/block/sda', 'block'
06:58:42 msg_exec: delay exec of sequence 13, [8061] already working on '/block/sda' 06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sda' 06:58:42 msg_exec: child [8062] created
06:58:42 running_moveto_queue: move sequence 13 [8062] to running queue '/block/sda' 06:58:42 msg_dump: sequence 14, 'add', '/block/sdb', 'block'
06:58:42 msg_exec: delay exec of sequence 14, [8057] already working on '/block/sdb' 06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sdb' 06:58:42 msg_exec: child [8063] created
06:58:42 running_moveto_queue: move sequence 14 [8063] to running queue '/block/sdb' 06:58:42 msg_dump: sequence 15, 'add', '/block/sdc', 'block'
06:58:42 msg_exec: delay exec of sequence 15, [8058] already working on '/block/sdc' 06:58:42 delayed_moveto_queue: move event to delayed queue '/block/sdc' 06:58:42 msg_exec: child [8064] created
06:58:42 running_moveto_queue: move sequence 15 [8064] to running queue '/block/sdc' 06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8057
06:58:43 sig_handler: exec finished, pid 8058
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8059
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8060
06:58:43 sig_handler: exec finished, pid 8061
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8062
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8063
06:58:43 sig_handler: caught signal 17
06:58:43 sig_handler: exec finished, pid 8064
Makefile +2 -0
@@ -232,6 +232,8 @@ @echo \#define UDEV_CONFIG_FILE \"$(configdir)\udev.conf\" >> $@ @echo \#define UDEV_RULES_FILE \"$(configdir)\udev.rules\" >> $@ @echo \#define UDEV_PERMISSION_FILE \"$(configdir)\udev.permissions\" >> $@ + @echo \#define UDEV_BIN \"$(PWD)/udev\" >> $@ + @echo \#define UDEVD_BIN \"$(PWD)/udevd\" >> $@ # config files automatically generated GEN_CONFIGS = $(LOCAL_CFG_DIR)/udev.conf
test/udevd_test.sh +44 -11
87 lines not on this page · raw message
udev.c +0 -2
@@ -45,7 +45,6 @@switch (signum) {case SIGINT :case SIGTERM : -case SIGKILL :sysbus_disconnect ();udevdb_exit ();exit (20 + signum);
@@ -143,7 +142,6 @@/* set up a default signal handler for now */ signal (SIGINT , sig_handler);signal (SIGTERM , sig_handler); -signal (SIGKILL , sig_handler);/* initialize the naming deamon */ namedev_init ();
udevd.c +128 -60
296 lines not on this page · raw message
udevd.h +5 -5
@@ -23,18 +23,18 @@#include "list.h" -#define UDEV_EXEC "./udev" -#define UDEVD_EXEC "./udevd" -#define UDEVD_TIMEOUT_SECONDS 60 -#define EVENT_TIMEOUT_SECONDS 5 +#define FIRST_EVENT_TIMEOUT_SEC 1 +#define EVENT_TIMEOUT_SEC 5 +#define UDEVSEND_RETRY_COUNT 50/* x 10 millisec */ -#define IPC_KEY_ID 0 +#define IPC_KEY_ID 1#define HOTPLUGMSGTYPE 44struct hotplug_msg {long mtype;struct list_head list; +pid_t pid;int seqnum;time_t queue_time;char action[8 ];
udevsend.c +6 -4
@@ -34,6 +34,7 @@#include <wait.h> #include "udev.h" +#include "udev_version.h" #include "udevd.h" #include "logging.h"
@@ -64,7 +65,7 @@static int build_hotplugmsg (struct hotplug_msg *msg,char *action,char *devpath,char *subsystem,int seqnum) { -memset (msg,0x00 ,sizeof (msg)); +memset (msg,0x00 ,sizeof (*msg)); msg->mtype =HOTPLUGMSGTYPE ; msg->seqnum = seqnum;strncpy (msg->action, action,8 );
@@ -88,7 +89,7 @@/* daemon */ setsid ();chdir ("/" ); -execl (UDEVD_EXEC ,"udevd" ,NULL ); +execl (UDEVD_BIN ,"udevd" ,NULL );dbg ("exec of daemon failed" );exit (1 );case -1 :
@@ -150,7 +151,8 @@ seq =atoi (seqnum);/* create ipc message queue or get id of our existing one */ - key =ftok (UDEVD_EXEC ,IPC_KEY_ID ); + key =ftok (UDEVD_BIN ,IPC_KEY_ID ); +dbg ("using ipc queue 0x%0x" , key); size =build_hotplugmsg (&message, action, devpath, subsystem, seq); msgid =msgget (key,IPC_CREAT );if (msgid ==-1 ) {
@@ -168,7 +170,7 @@/* get state of ipc queue */ tspec.tv_sec =0 ; tspec.tv_nsec =10000000 ;/* 10 millisec */ - loop =30 ; + loop =UDEVSEND_RETRY_COUNT ;while (loop--) { retval =msgctl (msgid,IPC_STAT , &msg_queue);if (retval ==-1 ) {
Quoted 3 lines · Kay Sievers
All problems magically go away with threads, cause we share the same address space and let the kernel schedule our tasks.
Ok, that makes more sense. Thanks for explaining it.
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 31 lines · Kay Sievers
Quoted 17 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.Quoted 6 lines
Quoted 2 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Quoted 6 lines
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
I can't think of any problem with that.
Here is the next round. We have three queues now. All incoming messages are queued in
msg_listand if nothing is missing we move it to therunning_listand exec in the background.
If the exec comes back, it removes the message from therunning_listand frees the message.
Quoted 4 lines
Before we exec, we check the
running_listif there is a udev running on the same device path. If yes, we move the message to thedelay_list. If the former exec comes back, we move the message to therunning_listand exec it.
Oh, sorry forget about it now.
I will come up with something better tested.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 32 lines · Kay Sievers
Quoted 31 lines · Kay Sievers
Quoted 17 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.Quoted 6 lines
Quoted 2 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Quoted 6 lines
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
I can't think of any problem with that.
Here is the next round. We have three queues now. All incoming messages are queued in
msg_listand if nothing is missing we move it to therunning_listand exec in the background.
If the exec comes back, it removes the message from therunning_listand frees the message.
Quoted 7 lines
Quoted 4 lines
Before we exec, we check the
running_listif there is a udev running on the same device path. If yes, we move the message to thedelay_list. If the former exec comes back, we move the message to therunning_listand exec it.Oh, sorry forget about it now.
I will come up with something better tested.
Oops, I just applied this version :)
I'll try testing this later on today.
thanks,
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 38 lines · Greg KH
Quoted 37 lines · Kay Sievers
Quoted 35 lines · Kay Sievers
Quoted 17 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.Quoted 6 lines
Quoted 2 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Quoted 6 lines
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
I can't think of any problem with that.
Here is the next round. We have three queues now. All incoming messages are queued in
msg_listand if nothing is missing we move it to therunning_listand exec in the background.
If the exec comes back, it removes the message from therunning_listand frees the message.Before we exec, we check the
running_listif there is a udev running on the same device path. If yes, we move the message to thedelay_list. If the former exec comes back, we move the message to therunning_listand exec it.
Quoted 6 lines
Quoted 2 lines
Oh, sorry forget about it now.
I will come up with something better tested.Oops, I just applied this version :)
I'll try testing this later on today.
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
thanks,
Kay
The result of the test script follows. I've sent SEQNUM=0 before starting the script, so we don't wait for the initial timeout. Look at exec 9 -> 12 -> 10 for the DEVPATH logic:
Jan 28 22:23:41 pim udev[24687]: main: connect failed, try starting daemon... Jan 28 22:23:41 pim udev[24689]: msg_queue_manager: msg queue manager, next expected is 0 Jan 28 22:23:41 pim udev[24689]: exec_queue_manager: exec list manager Jan 28 22:23:41 pim udev[24687]: main: daemon started Jan 28 22:23:41 pim udev[24689]: msg_queue_insert: add message seq 0 Jan 28 22:23:41 pim udev[24689]: msg_queue_manager: msg queue manager, next expected is 0 Jan 28 22:23:41 pim udev[24689]: msg_queue_manager: moved seq 0 to exec, next expected is 1 Jan 28 22:23:41 pim udev[24689]: exec_queue_manager: exec list manager Jan 28 22:23:41 pim udev[24689]: run_threads: ==> exec seq 0 working at '/' Jan 28 22:23:41 pim udev[24689]: exec_queue_manager: moved seq 0 to running list Jan 28 22:23:44 pim udev[24689]: run_threads: <== exec seq 0 came back Jan 28 22:23:44 pim udev[24689]: exec_queue_manager: exec list manager Jan 28 22:23:51 pim udev[24689]: msg_queue_insert: add message seq 3 Jan 28 22:23:51 pim udev[24689]: msg_queue_manager: msg queue manager, next expected is 1 Jan 28 22:23:51 pim udev[24689]: msg_queue_insert: add message seq 1 Jan 28 22:23:51 pim udev[24689]: msg_queue_insert: add message seq 2 Jan 28 22:23:51 pim udev[24689]: msg_queue_insert: add message seq 4 Jan 28 22:23:51 pim udev[24689]: msg_queue_insert: add message seq 5 Jan 28 22:23:51 pim udev[24689]: msg_queue_insert: add message seq 8 Jan 28 22:23:51 pim udev[24689]: msg_queue_insert: add message seq 6 Jan 28 22:23:51 pim udev[24689]: msg_queue_manager: moved seq 1 to exec, next expected is 2 Jan 28 22:23:51 pim udev[24689]: msg_queue_manager: moved seq 2 to exec, next expected is 3 Jan 28 22:23:51 pim udev[24689]: msg_queue_manager: moved seq 3 to exec, next expected is 4 Jan 28 22:23:51 pim udev[24689]: msg_queue_manager: moved seq 4 to exec, next expected is 5 Jan 28 22:23:51 pim udev[24689]: msg_queue_manager: moved seq 5 to exec, next expected is 6 Jan 28 22:23:51 pim udev[24689]: msg_queue_manager: moved seq 6 to exec, next expected is 7 Jan 28 22:23:51 pim udev[24689]: msg_dump_queue: sequence 8 in queue Jan 28 22:23:51 pim udev[24689]: msg_queue_manager: next event expires in 10 seconds Jan 28 22:23:51 pim udev[24689]: exec_queue_manager: exec list manager
Jan 28 22:23:51 pim udev[24689]: run_threads: ==> exec seq 1 working at '/block/sda' Jan 28 22:23:51 pim udev[24689]: exec_queue_manager: moved seq 1 to running list
Jan 28 22:23:51 pim udev[24689]: run_threads: ==> exec seq 2 working at '/block/sdb' Jan 28 22:23:51 pim udev[24689]: exec_queue_manager: moved seq 2 to running list
Jan 28 22:23:51 pim udev[24689]: run_threads: ==> exec seq 3 working at '/block/sdc' Jan 28 22:23:51 pim udev[24689]: exec_queue_manager: moved seq 3 to running list Jan 28 22:23:51 pim udev[24689]: exec_queue_manager: delay seq 4, cause seq 3 already working on '/block/sdc' Jan 28 22:23:51 pim udev[24689]: exec_queue_manager: delay seq 5, cause seq 2 already working on '/block/sdb' Jan 28 22:23:51 pim udev[24689]: exec_queue_manager: delay seq 6, cause seq 1 already working on '/block/sda' Jan 28 22:23:53 pim udev[24689]: msg_queue_insert: add message seq 9 Jan 28 22:23:53 pim udev[24689]: msg_queue_insert: add message seq 11 Jan 28 22:23:53 pim udev[24689]: msg_queue_insert: add message seq 10 Jan 28 22:23:53 pim udev[24689]: msg_queue_manager: msg queue manager, next expected is 7 Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 8 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 9 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 10 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 11 in queue Jan 28 22:23:53 pim udev[24689]: msg_queue_manager: next event expires in 8 seconds Jan 28 22:23:53 pim udev[24689]: msg_queue_insert: add message seq 13 Jan 28 22:23:53 pim udev[24689]: msg_queue_manager: msg queue manager, next expected is 7 Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 8 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 9 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 10 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 11 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 13 in queue Jan 28 22:23:53 pim udev[24689]: msg_queue_manager: next event expires in 8 seconds Jan 28 22:23:53 pim udev[24689]: msg_queue_insert: add message seq 14 Jan 28 22:23:53 pim udev[24689]: msg_queue_manager: msg queue manager, next expected is 7 Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 8 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 9 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 10 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 11 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 13 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 14 in queue Jan 28 22:23:53 pim udev[24689]: msg_queue_manager: next event expires in 8 seconds Jan 28 22:23:53 pim udev[24689]: msg_queue_insert: add message seq 15 Jan 28 22:23:53 pim udev[24689]: msg_queue_manager: msg queue manager, next expected is 7 Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 8 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 9 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 10 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 11 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 13 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 14 in queue Jan 28 22:23:53 pim udev[24689]: msg_dump_queue: sequence 15 in queue Jan 28 22:23:53 pim udev[24689]: msg_queue_manager: next event expires in 8 seconds Jan 28 22:23:54 pim udev[24689]: run_threads: <== exec seq 1 came back Jan 28 22:23:54 pim udev[24689]: run_threads: <== exec seq 2 came back Jan 28 22:23:54 pim udev[24689]: run_threads: <== exec seq 3 came back Jan 28 22:23:54 pim udev[24689]: exec_queue_manager: exec list manager
Jan 28 22:23:54 pim udev[24689]: run_threads: ==> exec seq 4 working at '/block/sdc' Jan 28 22:23:54 pim udev[24689]: exec_queue_manager: moved seq 4 to running list
Jan 28 22:23:54 pim udev[24689]: run_threads: ==> exec seq 5 working at '/block/sdb' Jan 28 22:23:54 pim udev[24689]: exec_queue_manager: moved seq 5 to running list
Jan 28 22:23:54 pim udev[24689]: run_threads: ==> exec seq 6 working at '/block/sda' Jan 28 22:23:54 pim udev[24689]: exec_queue_manager: moved seq 6 to running list Jan 28 22:23:55 pim udev[24689]: msg_queue_insert: add message seq 12 Jan 28 22:23:55 pim udev[24689]: msg_queue_manager: msg queue manager, next expected is 7 Jan 28 22:23:55 pim udev[24689]: msg_dump_queue: sequence 8 in queue Jan 28 22:23:55 pim udev[24689]: msg_dump_queue: sequence 9 in queue Jan 28 22:23:55 pim udev[24689]: msg_dump_queue: sequence 10 in queue Jan 28 22:23:55 pim udev[24689]: msg_dump_queue: sequence 11 in queue Jan 28 22:23:55 pim udev[24689]: msg_dump_queue: sequence 12 in queue Jan 28 22:23:55 pim udev[24689]: msg_dump_queue: sequence 13 in queue Jan 28 22:23:55 pim udev[24689]: msg_dump_queue: sequence 14 in queue Jan 28 22:23:55 pim udev[24689]: msg_dump_queue: sequence 15 in queue Jan 28 22:23:55 pim udev[24689]: msg_queue_manager: next event expires in 6 seconds Jan 28 22:23:57 pim udev[24689]: run_threads: <== exec seq 4 came back Jan 28 22:23:57 pim udev[24689]: run_threads: <== exec seq 5 came back Jan 28 22:23:57 pim udev[24689]: run_threads: <== exec seq 6 came back Jan 28 22:23:57 pim udev[24689]: exec_queue_manager: exec list manager Jan 28 22:24:01 pim udev[24689]: msg_queue_manager: msg queue manager, next expected is 7 Jan 28 22:24:01 pim udev[24689]: msg_queue_manager: moved seq 8 to exec, reset next expected to 9 Jan 28 22:24:01 pim udev[24689]: msg_queue_manager: moved seq 9 to exec, next expected is 10 Jan 28 22:24:01 pim udev[24689]: msg_queue_manager: moved seq 10 to exec, next expected is 11 Jan 28 22:24:01 pim udev[24689]: msg_queue_manager: moved seq 11 to exec, next expected is 12 Jan 28 22:24:01 pim udev[24689]: msg_queue_manager: moved seq 12 to exec, next expected is 13 Jan 28 22:24:01 pim udev[24689]: msg_queue_manager: moved seq 13 to exec, next expected is 14 Jan 28 22:24:01 pim udev[24689]: msg_queue_manager: moved seq 14 to exec, next expected is 15 Jan 28 22:24:01 pim udev[24689]: msg_queue_manager: moved seq 15 to exec, next expected is 16 Jan 28 22:24:01 pim udev[24689]: exec_queue_manager: exec list manager
Jan 28 22:24:01 pim udev[24689]: run_threads: ==> exec seq 8 working at '/block/sdb' Jan 28 22:24:01 pim udev[24689]: exec_queue_manager: moved seq 8 to running list
Jan 28 22:24:01 pim udev[24689]: run_threads: ==> exec seq 9 working at '/block/sdc' Jan 28 22:24:01 pim udev[24689]: exec_queue_manager: moved seq 9 to running list Jan 28 22:24:01 pim udev[24689]: exec_queue_manager: delay seq 10, cause seq 9 already working on '/block/sdc' Jan 28 22:24:01 pim udev[24689]: exec_queue_manager: delay seq 11, cause seq 8 already working on '/block/sdb'
Jan 28 22:24:01 pim udev[24689]: run_threads: ==> exec seq 12 working at '/block/sda' Jan 28 22:24:01 pim udev[24689]: exec_queue_manager: moved seq 12 to running list Jan 28 22:24:01 pim udev[24689]: exec_queue_manager: delay seq 13, cause seq 12 already working on '/block/sda' Jan 28 22:24:01 pim udev[24689]: exec_queue_manager: delay seq 14, cause seq 8 already working on '/block/sdb' Jan 28 22:24:01 pim udev[24689]: exec_queue_manager: delay seq 15, cause seq 9 already working on '/block/sdc' Jan 28 22:24:04 pim udev[24689]: run_threads: <== exec seq 8 came back Jan 28 22:24:04 pim udev[24689]: run_threads: <== exec seq 9 came back Jan 28 22:24:04 pim udev[24689]: run_threads: <== exec seq 12 came back Jan 28 22:24:04 pim udev[24689]: exec_queue_manager: exec list manager
Jan 28 22:24:04 pim udev[24689]: run_threads: ==> exec seq 10 working at '/block/sdc' Jan 28 22:24:04 pim udev[24689]: exec_queue_manager: moved seq 10 to running list
Jan 28 22:24:04 pim udev[24689]: run_threads: ==> exec seq 11 working at '/block/sdb' Jan 28 22:24:04 pim udev[24689]: exec_queue_manager: moved seq 11 to running list
Jan 28 22:24:04 pim udev[24689]: run_threads: ==> exec seq 13 working at '/block/sda' Jan 28 22:24:04 pim udev[24689]: exec_queue_manager: moved seq 13 to running list Jan 28 22:24:04 pim udev[24689]: exec_queue_manager: delay seq 14, cause seq 11 already working on '/block/sdb' Jan 28 22:24:04 pim udev[24689]: exec_queue_manager: delay seq 15, cause seq 10 already working on '/block/sdc' Jan 28 22:24:07 pim udev[24689]: run_threads: <== exec seq 10 came back Jan 28 22:24:07 pim udev[24689]: run_threads: <== exec seq 11 came back Jan 28 22:24:07 pim udev[24689]: run_threads: <== exec seq 13 came back Jan 28 22:24:07 pim udev[24689]: exec_queue_manager: exec list manager
Jan 28 22:24:07 pim udev[24689]: run_threads: ==> exec seq 14 working at '/block/sdb' Jan 28 22:24:07 pim udev[24689]: exec_queue_manager: moved seq 14 to running list
Jan 28 22:24:07 pim udev[24689]: run_threads: ==> exec seq 15 working at '/block/sdc' Jan 28 22:24:07 pim udev[24689]: exec_queue_manager: moved seq 15 to running list Jan 28 22:24:10 pim udev[24689]: run_threads: <== exec seq 14 came back Jan 28 22:24:10 pim udev[24689]: run_threads: <== exec seq 15 came back Jan 28 22:24:10 pim udev[24689]: exec_queue_manager: exec list manager
===== Makefile 1.93 vs edited =====
Makefile +1 -1
@@ -255,7 +255,7 @@ $(STRIPCMD) $@ $(DAEMON): udevd.h udevd.o udevd.o logging.o - $(LD) $(LDFLAGS) -o $@ $(CRT0) udevd.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) + $(LD) $(LDFLAGS) -lpthread -o $@ $(CRT0) udevd.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $@ $(SENDER): udevd.h udevsend.o udevd.o logging.o
===== udevd.c 1.7 vs edited =====
udevd.c +240 -228
562 lines not on this page · raw message
===== udevd.h 1.4 vs edited =====
udevd.h +5 -3
@@ -23,16 +23,18 @@#include "list.h" +#define UDEV_MAGIC "udev_" UDEV_VERSION#define FIRST_EVENT_TIMEOUT_SEC 1 -#define EVENT_TIMEOUT_SEC 5 -#define UDEVSEND_RETRY_COUNT 50/* x 10 millisec */ +#define EVENT_TIMEOUT_SEC 10 +#define UDEVD_START_TIMEOUT 20/* x 100 millisec */ +#define UDEVD_PORT 44444#define IPC_KEY_ID 1#define HOTPLUGMSGTYPE 44struct hotplug_msg { -long mtype; +char magic[20 ];struct list_head list;pid_t pid;int seqnum;
===== udevsend.c 1.8 vs edited =====
udevsend.c +70 -29
167 lines not on this page · raw message
===== test/udevd_test.sh 1.4 vs edited =====
test/udevd_test.sh +1 -1
@@ -1,7 +1,7 @@ #!/bin/bash # kill daemon, first event will start it again -killall udevd +#killall udevd # 3 x connect/disconnect sequence of sda/sdb/sdc
Quoted 72 lines · Kay Sievers
Quoted 38 lines · Greg KH
Quoted 37 lines · Kay Sievers
Quoted 35 lines · Kay Sievers
Quoted 17 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.Quoted 6 lines
Quoted 2 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Quoted 6 lines
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
I can't think of any problem with that.
Here is the next round. We have three queues now. All incoming messages are queued in
msg_listand if nothing is missing we move it to therunning_listand exec in the background.
If the exec comes back, it removes the message from therunning_listand frees the message.Before we exec, we check the
running_listif there is a udev running on the same device path. If yes, we move the message to thedelay_list. If the former exec comes back, we move the message to therunning_listand exec it.Quoted 6 lines
Quoted 2 lines
Oh, sorry forget about it now.
I will come up with something better tested.Oops, I just applied this version :)
I'll try testing this later on today.
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.
Quoted 4 lines
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 ACTIONd SEQNUM=0 ./udevsend /abc
Here is the next version, that also does the exec. Please have a look.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 72 lines · Kay Sievers
Quoted 38 lines · Greg KH
Quoted 37 lines · Kay Sievers
Quoted 35 lines · Kay Sievers
Quoted 17 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.Quoted 6 lines
Quoted 2 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Quoted 6 lines
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
I can't think of any problem with that.
Here is the next round. We have three queues now. All incoming messages are queued in
msg_listand if nothing is missing we move it to therunning_listand exec in the background.
If the exec comes back, it removes the message from therunning_listand frees the message.Before we exec, we check the
running_listif there is a udev running on the same device path. If yes, we move the message to thedelay_list. If the former exec comes back, we move the message to therunning_listand exec it.Quoted 6 lines
Quoted 2 lines
Oh, sorry forget about it now.
I will come up with something better tested.Oops, I just applied this version :)
I'll try testing this later on today.
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.
Quoted 4 lines
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
Sorry, on my keyboard 'a' and 'y' are direct neighbours :)
thanks,
Kay
===== Makefile 1.93 vs edited =====
Makefile +1 -1
@@ -255,7 +255,7 @@ $(STRIPCMD) $@ $(DAEMON): udevd.h udevd.o udevd.o logging.o - $(LD) $(LDFLAGS) -o $@ $(CRT0) udevd.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) + $(LD) $(LDFLAGS) -lpthread -o $@ $(CRT0) udevd.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $@ $(SENDER): udevd.h udevsend.o udevd.o logging.o
===== udevd.c 1.7 vs edited =====
udevd.c +253 -217
571 lines not on this page · raw message
===== udevd.h 1.4 vs edited =====
udevd.h +4 -3
@@ -23,16 +23,17 @@#include "list.h" -#define FIRST_EVENT_TIMEOUT_SEC 1 +#define UDEV_MAGIC "udev_" UDEV_VERSION#define EVENT_TIMEOUT_SEC 5 -#define UDEVSEND_RETRY_COUNT 50/* x 10 millisec */ +#define UDEVD_START_TIMEOUT 20/* x 100 millisec */ +#define UDEVD_PORT 44444#define IPC_KEY_ID 1#define HOTPLUGMSGTYPE 44struct hotplug_msg { -long mtype; +char magic[20 ];struct list_head list;pid_t pid;int seqnum;
===== udevsend.c 1.8 vs edited =====
udevsend.c +47 -30
125 lines not on this page · raw message
===== test/udevd_test.sh 1.4 vs edited =====
test/udevd_test.sh +1 -1
@@ -1,7 +1,7 @@ #!/bin/bash # kill daemon, first event will start it again -killall udevd +#killall udevd # 3 x connect/disconnect sequence of sda/sdb/sdc
Quoted 73 lines · Kay Sievers
Quoted 72 lines · Kay Sievers
Quoted 38 lines · Greg KH
Quoted 37 lines · Kay Sievers
Quoted 35 lines · Kay Sievers
Quoted 17 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.Quoted 6 lines
Quoted 2 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Quoted 6 lines
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
I can't think of any problem with that.
Here is the next round. We have three queues now. All incoming messages are queued in
msg_listand if nothing is missing we move it to therunning_listand exec in the background.
If the exec comes back, it removes the message from therunning_listand frees the message.Before we exec, we check the
running_listif there is a udev running on the same device path. If yes, we move the message to thedelay_list. If the former exec comes back, we move the message to therunning_listand exec it.Quoted 6 lines
Quoted 2 lines
Oh, sorry forget about it now.
I will come up with something better tested.Oops, I just applied this version :)
I'll try testing this later on today.
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.
Quoted 4 lines
Quoted 4 lines
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.
thanks,
Kay
===== Makefile 1.93 vs edited =====
Makefile +1 -1
@@ -255,7 +255,7 @@ $(STRIPCMD) $@ $(DAEMON): udevd.h udevd.o udevd.o logging.o - $(LD) $(LDFLAGS) -o $@ $(CRT0) udevd.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) + $(LD) $(LDFLAGS) -lpthread -o $@ $(CRT0) udevd.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $@ $(SENDER): udevd.h udevsend.o udevd.o logging.o
===== udevd.c 1.7 vs edited =====
udevd.c +262 -199
573 lines not on this page · raw message
===== udevd.h 1.4 vs edited =====
udevd.h +6 -7
@@ -4,6 +4,7 @@* Userspace devfs * * Copyright (C) 2004 Ling, Xiaofeng <[email protected]> +* Copyright (C) 2004 Kay Sievers <[email protected]> * * * This program is free software; you can redistribute it and/or modify it
@@ -23,16 +24,14 @@#include "list.h" -#define FIRST_EVENT_TIMEOUT_SEC 1 +#define UDEV_MAGIC "udev_" UDEV_VERSION#define EVENT_TIMEOUT_SEC 5 -#define UDEVSEND_RETRY_COUNT 50/* x 10 millisec */ - -#define IPC_KEY_ID 1 -#define HOTPLUGMSGTYPE 44 - +#define UDEVD_START_TIMEOUT 20/* x 100 millisec */ +#define UDEVD_SOCKET "/tmp/udevd.socket" +#define UDEVD_LOCK "/var/run/udevd.pid"struct hotplug_msg { -long mtype; +char magic[20 ];struct list_head list;pid_t pid;int seqnum;
===== udevsend.c 1.8 vs edited =====
udevsend.c +47 -30
125 lines not on this page · raw message
===== test/udevd_test.sh 1.4 vs edited =====
test/udevd_test.sh +1 -1
@@ -1,7 +1,7 @@ #!/bin/bash # kill daemon, first event will start it again -killall udevd +#killall udevd # 3 x connect/disconnect sequence of sda/sdb/sdc
Quoted 74 lines · Kay Sievers
Quoted 73 lines · Kay Sievers
Quoted 72 lines · Kay Sievers
Quoted 38 lines · Greg KH
Quoted 37 lines · Kay Sievers
Quoted 35 lines · Kay Sievers
Quoted 17 lines · Greg KH
Quoted 9 lines · Kay Sievers
Quoted 8 lines · Greg KH
Quoted 6 lines · Kay Sievers
1. We are much too slow.
We want to exec the real udev in the background, but a 'remove' is much much faster than a 'add', so we have a problem.
Question: is it neccessary to order events for different devpath's? If no, we maywait_pid()for the exec only if we have another udev working on the same devpath.Quoted 6 lines
Quoted 2 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Quoted 6 lines
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
I can't think of any problem with that.
Here is the next round. We have three queues now. All incoming messages are queued in
msg_listand if nothing is missing we move it to therunning_listand exec in the background.
If the exec comes back, it removes the message from therunning_listand frees the message.Before we exec, we check the
running_listif there is a udev running on the same device path. If yes, we move the message to thedelay_list. If the former exec comes back, we move the message to therunning_listand exec it.Quoted 6 lines
Quoted 2 lines
Oh, sorry forget about it now.
I will come up with something better tested.Oops, I just applied this version :)
I'll try testing this later on today.
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.
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
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.
thanks,
Kay
===== Makefile 1.93 vs edited =====
Makefile +1 -1
@@ -255,7 +255,7 @@ $(STRIPCMD) $@ $(DAEMON): udevd.h udevd.o udevd.o logging.o - $(LD) $(LDFLAGS) -o $@ $(CRT0) udevd.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) + $(LD) $(LDFLAGS) -lpthread -o $@ $(CRT0) udevd.o logging.o $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $@ $(SENDER): udevd.h udevsend.o udevd.o logging.o
===== udevd.c 1.7 vs edited =====
udevd.c +274 -206
590 lines not on this page · raw message
===== udevd.h 1.4 vs edited =====
udevd.h +13 -7
@@ -4,6 +4,7 @@* Userspace devfs * * Copyright (C) 2004 Ling, Xiaofeng <[email protected]> +* Copyright (C) 2004 Kay Sievers <[email protected]> * * * 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;
===== udevsend.c 1.8 vs edited =====
udevsend.c +48 -30
126 lines not on this page · raw message
===== test/udevd_test.sh 1.4 vs edited =====
test/udevd_test.sh +3 -5
@@ -1,9 +1,7 @@ -#!/bin/bash +#!/bin/sh -# kill daemon, first event will start it again -killall udevd - -# 3 x connect/disconnect sequence of sda/sdb/sdc +# add/rem/add/rem/add sequence of sda/sdb/sdc +# a few days longer and the socket of my usb-flash-reader is gone :) export SEQNUM=3 export ACTION=add
Quoted 7 lines · Kay Sievers
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.
Very sorry for the delay, been busy with other work these past few days.
I've applied this patch, and pushed it to the repo. I'll try to test it some more myself early next week, and let you know how it goes.
thanks,
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Greg KH
Quoted 7 lines · Kay Sievers
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.
Quoted 4 lines
Very sorry for the delay, been busy with other work these past few days.
I've applied this patch, and pushed it to the repo. I'll try to test it some more myself early next week, and let you know how it goes.
Here is a small cleanup and better Makefile integration.
udevd and udevsender are now installed. Just switch HOTPLUG_EXEC from ROOT to SENDER before install and udevsend will be called.
We may add the location of the socket and lock file to the config, if this is needed.
thanks,
Kay
===== Makefile 1.94 vs edited =====
Makefile +12 -5
@@ -38,6 +38,7 @@ INSTALL_DIR = /usr/local/bin RELEASE_NAME = $(ROOT)-$(VERSION) LOCAL_CFG_DIR = etc/udev +HOTPLUG_EXEC = $(ROOT) DESTDIR = # override this to make udev look in a different location for it's config files
@@ -232,8 +233,10 @@ @echo \#define UDEV_CONFIG_FILE \"$(configdir)\udev.conf\" >> $@ @echo \#define UDEV_RULES_FILE \"$(configdir)\udev.rules\" >> $@ @echo \#define UDEV_PERMISSION_FILE \"$(configdir)\udev.permissions\" >> $@ - @echo \#define UDEV_BIN \"$(PWD)/udev\" >> $@ - @echo \#define UDEVD_BIN \"$(PWD)/udevd\" >> $@ + @echo \#define UDEV_BIN \"$(DESTDIR)$(sbindir)/udev\" >> $@ + @echo \#define UDEVD_BIN \"$(DESTDIR)$(sbindir)/udevd\" >> $@ + @echo \#define UDEVD_SOCK \"$(udevdir)/\.udevd.sock\" >> $@ + @echo \#define UDEVD_LOCK \"$(udevdir)/\.udevd.lock\" >> $@ # config files automatically generated GEN_CONFIGS = $(LOCAL_CFG_DIR)/udev.conf
@@ -338,6 +341,8 @@ $(INSTALL) -d $(DESTDIR)$(udevdir) $(INSTALL) -d $(DESTDIR)$(hotplugdir) $(INSTALL_PROGRAM) -D $(ROOT) $(DESTDIR)$(sbindir)/$(ROOT) + $(INSTALL_PROGRAM) -D $(DAEMON) $(DESTDIR)$(sbindir)/$(DAEMON) + $(INSTALL_PROGRAM) -D $(SENDER) $(DESTDIR)$(sbindir)/$(SENDER) $(INSTALL_PROGRAM) -D $(HELPER) $(DESTDIR)$(sbindir)/$(HELPER) @if [ "x$(USE_LSB)" = "xtrue" ]; then \ $(INSTALL_PROGRAM) -D etc/init.d/udev.init.LSB $(DESTDIR)$(initdir)/udev; \
@@ -347,8 +352,8 @@ fi $(INSTALL_DATA) -D udev.8 $(DESTDIR)$(mandir)/man8/udev.8 $(INSTALL_DATA) -D udevinfo.8 $(DESTDIR)$(mandir)/man8/udevinfo.8 - - rm -f $(DESTDIR)$(hotplugdir)/udev.hotplug - - ln -f -s $(sbindir)/$(ROOT) $(DESTDIR)$(hotplugdir)/udev.hotplug + - rm -f $(DESTDIR)$(hotplugdir)/$(HOTPLUG_EXEC).hotplug + - ln -f -s $(sbindir)/$(HOTPLUG_EXEC) $(DESTDIR)$(hotplugdir)/$(HOTPLUG_EXEC).hotplug @extras="$(EXTRAS)" ; for target in $$extras ; do \ echo $$target ; \ $(MAKE) prefix=$(prefix) LD="$(LD)" SYSFS="$(SYSFS)" \
@@ -356,7 +361,7 @@ done ; \ uninstall: uninstall-dbus-policy - - rm $(hotplugdir)/udev.hotplug + - rm $(hotplugdir)/$(HOTPLUG_EXEC).hotplug - rm $(configdir)/udev.permissions - rm $(configdir)/udev.rules - rm $(configdir)/udev.conf
@@ -364,6 +369,8 @@ - rm $(mandir)/man8/udev.8 - rm $(mandir)/man8/udevinfo.8 - rm $(sbindir)/$(ROOT) + - rm $(sbindir)/$(DAEMON) + - rm $(sbindir)/$(SENDER) - rm $(sbindir)/$(HELPER) - rmdir $(hotplugdir) - rmdir $(configdir)
===== udevd.c 1.8 vs edited =====
udevd.c +13 -10
@@ -71,7 +71,6 @@ msg->seqnum, msg->action, msg->devpath, msg->subsystem); } -/* allocates a new message */ static struct hotplug_msg *msg_create (void ) {struct hotplug_msg *new_msg;
@@ -81,10 +80,15 @@dbg ("error malloc" );return NULL ; } -memset (new_msg,0x00 ,sizeof (struct hotplug_msg ));return new_msg; } +static void msg_delete (struct hotplug_msg *msg) +{ +if (msg !=NULL ) +free (msg); +} +/* orders the message in the queue by sequence number */ static void msg_queue_insert (struct hotplug_msg *msg) {
@@ -143,7 +147,7 @@list_del_init (&msg->list);pthread_mutex_unlock (&running_lock); -free (msg); +msg_delete (msg);/* signal queue activity to exec manager */ pthread_mutex_lock (&exec_active_lock);
@@ -289,6 +293,7 @@if (strncmp (msg->magic,UDEV_MAGIC ,sizeof (UDEV_MAGIC )) !=0 ) {dbg ("message magic '%s' doesn't match, ignore it" , msg->magic); +msg_delete (msg); goto exit; }
@@ -307,7 +312,7 @@case SIGINT :case SIGTERM :unlink (UDEVD_LOCK ); -unlink (UDEVD_SOCKET ); +unlink (UDEVD_SOCK );exit (20 + signum);break ;default :
@@ -320,7 +325,6 @@char string[50 ];int lock_file; -/* see if we can open */ lock_file =open (UDEVD_LOCK ,O_RDWR |O_CREAT ,0x640 );if (lock_file <0 )return -1 ;
@@ -359,9 +363,9 @@memset (&saddr,0x00 ,sizeof (saddr)); saddr.sun_family =AF_LOCAL ; -strcpy (saddr.sun_path,UDEVD_SOCKET ); +strcpy (saddr.sun_path,UDEVD_SOCK ); -unlink (UDEVD_SOCKET ); +unlink (UDEVD_SOCK ); ssock =socket (AF_LOCAL ,SOCK_STREAM ,0 );if (ssock ==-1 ) {dbg ("error getting socket" );
@@ -399,14 +403,13 @@while (1 ) { csock =accept (ssock, &caddr, &clen);if (csock <0 ) { -if (errno ==EINTR ) -continue ;dbg ("client accept failed\n" ); +continue ; }pthread_create (&cli_tid, &thr_attr, client_threads, (void *) csock); } exit:close (ssock); -unlink (UDEVD_SOCKET ); +unlink (UDEVD_SOCK );exit (1 ); }
===== udevd.h 1.5 vs edited =====
udevd.h +1 -10
@@ -24,18 +24,9 @@#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 UDEV_MAGIC "udevd_" 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 ];
===== udevsend.c 1.9 vs edited =====
udevsend.c +1 -1
@@ -159,7 +159,7 @@memset (&saddr,0x00 ,sizeof (saddr)); saddr.sun_family =AF_LOCAL ; -strcpy (saddr.sun_path,UDEVD_SOCKET ); +strcpy (saddr.sun_path,UDEVD_SOCK );/* try to connect, if it fails start daemon */ retval =connect (sock, &saddr,sizeof (saddr));
Quoted 15 lines · Kay Sievers
Quoted 9 lines · Greg KH
Quoted 7 lines · Kay Sievers
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.
Quoted 4 lines
Very sorry for the delay, been busy with other work these past few days.
I've applied this patch, and pushed it to the repo. I'll try to test it some more myself early next week, and let you know how it goes.
Quoted 6 lines
Here is a small cleanup and better
Makefileintegration.
udevd and udevsender are now installed. Just switchHOTPLUG_EXECfrom ROOT to SENDER before install and udevsend will be called.We may add the location of the socket and lock file to the config, if this is needed.
Same patch with a fix for the stack size setting.
thanks,
Kay
===== Makefile 1.94 vs edited =====
Makefile +11 -4
@@ -38,6 +38,7 @@ INSTALL_DIR = /usr/local/bin RELEASE_NAME = $(ROOT)-$(VERSION) LOCAL_CFG_DIR = etc/udev +HOTPLUG_EXEC = $(ROOT) DESTDIR = # override this to make udev look in a different location for it's config files
@@ -232,8 +233,10 @@ @echo \#define UDEV_CONFIG_FILE \"$(configdir)\udev.conf\" >> $@ @echo \#define UDEV_RULES_FILE \"$(configdir)\udev.rules\" >> $@ @echo \#define UDEV_PERMISSION_FILE \"$(configdir)\udev.permissions\" >> $@ - @echo \#define UDEV_BIN \"$(PWD)/udev\" >> $@ - @echo \#define UDEVD_BIN \"$(PWD)/udevd\" >> $@ + @echo \#define UDEV_BIN \"$(DESTDIR)$(sbindir)/udev\" >> $@ + @echo \#define UDEVD_BIN \"$(DESTDIR)$(sbindir)/udevd\" >> $@ + @echo \#define UDEVD_SOCK \"$(udevdir)/\.udevd.sock\" >> $@ + @echo \#define UDEVD_LOCK \"$(udevdir)/\.udevd.lock\" >> $@ # config files automatically generated GEN_CONFIGS = $(LOCAL_CFG_DIR)/udev.conf
@@ -338,6 +341,8 @@ $(INSTALL) -d $(DESTDIR)$(udevdir) $(INSTALL) -d $(DESTDIR)$(hotplugdir) $(INSTALL_PROGRAM) -D $(ROOT) $(DESTDIR)$(sbindir)/$(ROOT) + $(INSTALL_PROGRAM) -D $(DAEMON) $(DESTDIR)$(sbindir)/$(DAEMON) + $(INSTALL_PROGRAM) -D $(SENDER) $(DESTDIR)$(sbindir)/$(SENDER) $(INSTALL_PROGRAM) -D $(HELPER) $(DESTDIR)$(sbindir)/$(HELPER) @if [ "x$(USE_LSB)" = "xtrue" ]; then \ $(INSTALL_PROGRAM) -D etc/init.d/udev.init.LSB $(DESTDIR)$(initdir)/udev; \
@@ -347,8 +352,8 @@ fi $(INSTALL_DATA) -D udev.8 $(DESTDIR)$(mandir)/man8/udev.8 $(INSTALL_DATA) -D udevinfo.8 $(DESTDIR)$(mandir)/man8/udevinfo.8 - - rm -f $(DESTDIR)$(hotplugdir)/udev.hotplug - - ln -f -s $(sbindir)/$(ROOT) $(DESTDIR)$(hotplugdir)/udev.hotplug + - rm -f $(DESTDIR)$(hotplugdir)/$(HOTPLUG_EXEC).hotplug + - ln -f -s $(sbindir)/$(HOTPLUG_EXEC) $(DESTDIR)$(hotplugdir)/udev.hotplug @extras="$(EXTRAS)" ; for target in $$extras ; do \ echo $$target ; \ $(MAKE) prefix=$(prefix) LD="$(LD)" SYSFS="$(SYSFS)" \
@@ -364,6 +369,8 @@ - rm $(mandir)/man8/udev.8 - rm $(mandir)/man8/udevinfo.8 - rm $(sbindir)/$(ROOT) + - rm $(sbindir)/$(DAEMON) + - rm $(sbindir)/$(SENDER) - rm $(sbindir)/$(HELPER) - rmdir $(hotplugdir) - rmdir $(configdir)
===== udevd.c 1.8 vs edited =====
udevd.c +15 -11
@@ -19,6 +19,7 @@* */ +#include <pthread.h> #include <stddef.h> #include <sys/types.h> #include <sys/wait.h>
@@ -33,7 +34,6 @@#include <sys/types.h> #include <sys/socket.h> #include <sys/un.h> -#include <pthread.h> #include "list.h" #include "udev.h"
@@ -71,7 +71,6 @@ msg->seqnum, msg->action, msg->devpath, msg->subsystem); } -/* allocates a new message */ static struct hotplug_msg *msg_create (void ) {struct hotplug_msg *new_msg;
@@ -81,10 +80,15 @@dbg ("error malloc" );return NULL ; } -memset (new_msg,0x00 ,sizeof (struct hotplug_msg ));return new_msg; } +static void msg_delete (struct hotplug_msg *msg) +{ +if (msg !=NULL ) +free (msg); +} +/* orders the message in the queue by sequence number */ static void msg_queue_insert (struct hotplug_msg *msg) {
@@ -143,7 +147,7 @@list_del_init (&msg->list);pthread_mutex_unlock (&running_lock); -free (msg); +msg_delete (msg);/* signal queue activity to exec manager */ pthread_mutex_lock (&exec_active_lock);
@@ -289,6 +293,7 @@if (strncmp (msg->magic,UDEV_MAGIC ,sizeof (UDEV_MAGIC )) !=0 ) {dbg ("message magic '%s' doesn't match, ignore it" , msg->magic); +msg_delete (msg); goto exit; }
@@ -307,7 +312,7 @@case SIGINT :case SIGTERM :unlink (UDEVD_LOCK ); -unlink (UDEVD_SOCKET ); +unlink (UDEVD_SOCK );exit (20 + signum);break ;default :
@@ -320,7 +325,6 @@char string[50 ];int lock_file; -/* see if we can open */ lock_file =open (UDEVD_LOCK ,O_RDWR |O_CREAT ,0x640 );if (lock_file <0 )return -1 ;
@@ -359,9 +363,9 @@memset (&saddr,0x00 ,sizeof (saddr)); saddr.sun_family =AF_LOCAL ; -strcpy (saddr.sun_path,UDEVD_SOCKET ); +strcpy (saddr.sun_path,UDEVD_SOCK ); -unlink (UDEVD_SOCKET ); +unlink (UDEVD_SOCK ); ssock =socket (AF_LOCAL ,SOCK_STREAM ,0 );if (ssock ==-1 ) {dbg ("error getting socket" );
@@ -389,6 +393,7 @@/* set default attributes for created threads */ pthread_attr_init (&thr_attr);pthread_attr_setdetachstate (&thr_attr,PTHREAD_CREATE_DETACHED ); +pthread_attr_setstacksize (&thr_attr,16 *1024 );/* init queue management */ pthread_create (&mgr_msg_tid, &thr_attr, msg_queue_manager,NULL );
@@ -399,14 +404,13 @@while (1 ) { csock =accept (ssock, &caddr, &clen);if (csock <0 ) { -if (errno ==EINTR ) -continue ;dbg ("client accept failed\n" ); +continue ; }pthread_create (&cli_tid, &thr_attr, client_threads, (void *) csock); } exit:close (ssock); -unlink (UDEVD_SOCKET ); +unlink (UDEVD_SOCK );exit (1 ); }
===== udevd.h 1.5 vs edited =====
udevd.h +1 -10
@@ -24,18 +24,9 @@#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 UDEV_MAGIC "udevd_" 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 ];
===== udevsend.c 1.9 vs edited =====
udevsend.c +1 -1
@@ -159,7 +159,7 @@memset (&saddr,0x00 ,sizeof (saddr)); saddr.sun_family =AF_LOCAL ; -strcpy (saddr.sun_path,UDEVD_SOCKET ); +strcpy (saddr.sun_path,UDEVD_SOCK );/* try to connect, if it fails start daemon */ retval =connect (sock, &saddr,sizeof (saddr));
Quoted 2 lines · Kay Sievers
Same patch with a fix for the stack size setting.
Nice, applied.
I also cleaned up the way the logging code works, so that now we can see what program is spitting out what messages in the syslog.
Also, udevsend can _almost_ be built with klibc. Any reason we have to use a struct sockaddr_un instead of just a struct sockaddr? If that is changed than only udevd would rely on glibc.
I don't mind udevd using glibc, I just want the programs that get run a lot of different times (udev and udevsend) to be as small as possible to get the best cache results. As udevd sticks around all the time, it's not as important. Sound sane to you?
thanks,
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Greg KH
Quoted 2 lines · Kay Sievers
Same patch with a fix for the stack size setting.
Nice, applied.
I also cleaned up the way the logging code works, so that now we can see what program is spitting out what messages in the syslog.
Fine, I've missed it too sometimes.
We may include unistd.h for get_pid()?
Quoted 3 lines
Also, udevsend can _almost_ be built with klibc. Any reason we have to use a struct
sockaddr_uninstead of just a struct sockaddr? If that is changed than only udevd would rely on glibc.
The sockaddr doesn't contain the 108 char long pathname of the socket file.
Quoted 4 lines
I don't mind udevd using glibc, I just want the programs that get run a lot of different times (udev and udevsend) to be as small as possible to get the best cache results. As udevd sticks around all the time, it's not as important. Sound sane to you?
Oh, nice. Good idea.
I have two alternatives attached:
01-udevsend-klibc.patch
not the nicest, but it works
01-klibc-unix-domain.patch
clean, but touches klibc sources by inserting the missing header file
thanks,
Kay
Makefile +2 -2
@@ -161,12 +161,12 @@ CFLAGS += $(WARNINGS) -I$(GCCINCDIR) LIB_OBJS = -lc LDFLAGS = - UDEVD = $(DAEMON) $(SENDER) + UDEVD = $(DAEMON) endif CFLAGS += -I$(PWD)/libsysfs -all: $(ROOT) $(UDEVD) $(HELPER) +all: $(ROOT) $(SENDER) $(UDEVD) $(HELPER) @extras="$(EXTRAS)" ; for target in $$extras ; do \ echo $$target ; \ $(MAKE) prefix=$(prefix) LD="$(LD)" SYSFS="$(SYSFS)" \
klibc/klibc/include/sys/un.h new file +10 -0
@@ -0,0 +1,10 @@ +/* +* sys/un.h +*/ + +#ifndef _UN_H +#define _UN_H + +#include <linux/un.h> + +#endif /* _UN_H */
udevsend.c +2 -2
@@ -163,7 +163,7 @@strcpy (saddr.sun_path,UDEVD_SOCK );/* try to connect, if it fails start daemon */ - retval =connect (sock, &saddr,sizeof (saddr)); + retval =connect (sock, (struct sockaddr *) &saddr,sizeof (saddr));if (retval !=-1 ) { goto send; }else {
@@ -182,7 +182,7 @@ tspec.tv_nsec =100000000 ;/* 100 millisec */ loop =UDEVSEND_CONNECT_RETRY ;while (loop--) { - retval =connect (sock, &saddr,sizeof (saddr)); + retval =connect (sock, (struct sockaddr *) &saddr,sizeof (saddr));if (retval !=-1 ) goto send;else
===== Makefile 1.96 vs edited =====
Makefile +2 -2
@@ -161,12 +161,12 @@ CFLAGS += $(WARNINGS) -I$(GCCINCDIR) LIB_OBJS = -lc LDFLAGS = - UDEVD = $(DAEMON) $(SENDER) + UDEVD = $(DAEMON) endif CFLAGS += -I$(PWD)/libsysfs -all: $(ROOT) $(UDEVD) $(HELPER) +all: $(ROOT) $(SENDER) $(UDEVD) $(HELPER) @extras="$(EXTRAS)" ; for target in $$extras ; do \ echo $$target ; \ $(MAKE) prefix=$(prefix) LD="$(LD)" SYSFS="$(SYSFS)" \
===== udevsend.c 1.12 vs edited =====
udevsend.c +6 -2
@@ -25,7 +25,11 @@#include <sys/types.h> #include <sys/socket.h> #include <sys/wait.h> +#ifdef __KLIBC__ +#include <linux/un.h> +#else #include <sys/un.h> +#endif #include <errno.h> #include <stdio.h> #include <stdlib.h>
@@ -163,7 +167,7 @@strcpy (saddr.sun_path,UDEVD_SOCK );/* try to connect, if it fails start daemon */ - retval =connect (sock, &saddr,sizeof (saddr)); + retval =connect (sock, (struct sockaddr *) &saddr,sizeof (saddr));if (retval !=-1 ) { goto send; }else {
@@ -182,7 +186,7 @@ tspec.tv_nsec =100000000 ;/* 100 millisec */ loop =UDEVSEND_CONNECT_RETRY ;while (loop--) { - retval =connect (sock, &saddr,sizeof (saddr)); + retval =connect (sock, (struct sockaddr *) &saddr,sizeof (saddr));if (retval !=-1 ) goto send;else
Quoted 5 lines · Kay Sievers
Quoted 4 lines · Greg KH
Quoted 2 lines · Kay Sievers
Same patch with a fix for the stack size setting.
Quoted 7 lines
Quoted 4 lines
Nice, applied.
I also cleaned up the way the logging code works, so that now we can see what program is spitting out what messages in the syslog.
Fine, I've missed it too sometimes.
We may includeunistd.hforget_pid()?
Is it needed for you to build? It seems to work for me :)
Quoted 5 lines
Quoted 3 lines
Also, udevsend can _almost_ be built with klibc. Any reason we have to use a struct
sockaddr_uninstead of just a struct sockaddr? If that is changed than only udevd would rely on glibc.The sockaddr doesn't contain the 108 char long pathname of the socket file.
Ah, ok, that makes more sense.
Quoted 5 lines
Quoted 4 lines
I don't mind udevd using glibc, I just want the programs that get run a lot of different times (udev and udevsend) to be as small as possible to get the best cache results. As udevd sticks around all the time, it's not as important. Sound sane to you?
Quoted 8 lines
Oh, nice. Good idea.
I have two alternatives attached:01-udevsend-klibc.patch
not the nicest, but it works01-klibc-unix-domain.patch
clean, but touches klibc sources by inserting the missing header file
I applied this version, and then cleaned up udevsend a bit more so now it builds a 2.5kb binary using klibc. That's very nice.
thanks,
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Greg KH
Quoted 7 lines · Kay Sievers
Quoted 6 lines · Greg KH
Quoted 2 lines · Kay Sievers
Same patch with a fix for the stack size setting.
Nice, applied.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I also cleaned up the way the logging code works, so that now we can see what program is spitting out what messages in the syslog.
Fine, I've missed it too sometimes.
We may includeunistd.hforget_pid()?Is it needed for you to build? It seems to work for me :)
No, it works without it, cause the linker finds the symbol later. But we use the function in udev.c and udevdb.c, so I thought we should include the header for the prototype:
In file included from udevdb.c:38:
logging.h: In function `init_logging':
logging.h:76: warning: implicit declaration of function `getpid'
Does the daemon work for you?
I would expect that you have more devices to connect than me. I have only a USB-flash-reader and a simple webcam :)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Kay Sievers
No, it works without it, cause the linker finds the symbol later. But we use the function in
udev.candudevdb.c, so I thought we should include the header for the prototype:In file included from udevdb.c:38:
logging.h: In function `init_logging':
logging.h:76: warning: implicit declaration of function `getpid'
Hm, I don't see that on my build. Must be using different versions of gcc or something. Send me a patch and I'll add it.
Quoted 1 line
Does the daemon work for you?
It does, quite nicely. I just tested a bunch of different devices, very nice job.
Quoted 2 lines
I would expect that you have more devices to connect than me. I have only a USB-flash-reader and a simple webcam :)
Well, I do have a box full of odd usb devices around here. I'll beat on this some more tomorrow morning and then get a release out there for the world to test too.
Very nice job.
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 16 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Greg KH
Sent: 2004Äê1ÔÂ27ÈÕ 3:28
To: Kay Sievers
Cc: [email protected]
Subject: Re: [patch] udevd - cleanup and better timeout handlingQuoted 4 lines
Quoted 3 lines
But how will we keep track of that? It's probably easier just to wait for each one to finish, right?
Quoted 10 lines
Quoted 1 line
We leave the message in the queue until we reach the
SIGCHLD for this
Quoted 2 lines
pid. So we can search the queue if we are already working on this devpath, and delay the new exec until the former exec comes back.
Ok, if that isn't too much trouble.
Quoted 2 lines
Is it feasible to run in parallel for different paths, or can you think of any problem?
Is it safe to run parallel or unsequential for different path? I worry about it. Some devices like usb disk, there will be a sequence of event for different path when pluging in, like /class/scsi_device/0:0:0:0
/class/scsi_host/host0
block/sda
block/sda1
block/sda2,
although currently, I can not give out an bad example, but I still worry that there maybe have in future.
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Greg KH
Quoted 5 lines · Kay Sievers
No, it works without it, cause the linker finds the symbol later. But we use the function in
udev.candudevdb.c, so I thought we should include the header for the prototype:
Quoted 6 lines
Quoted 3 lines
In file included from udevdb.c:38:
logging.h: In function `init_logging':
logging.h:76: warning: implicit declaration of function `getpid'Hm, I don't see that on my build. Must be using different versions of gcc or something. Send me a patch and I'll add it.
This includes the missing header for the use of getpid in logging.h.
thanks,
Kay
===== logging.h 1.6 vs edited =====
logging.h +1 -0
@@ -31,6 +31,7 @@#ifdef LOG #include <stdarg.h> +#include <unistd.h> #include <syslog.h> #undef info
Greg KH
AppliedQuoted 3 lines · Kay Sievers
This includes the missing header for the use of getpid in
logging.h.
Thanks, applied.
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Kay Sievers
===
udevd.c1.7 vs edited ==> ---1.7/udevd.cWed Jan 28 19:52:44 2004
+++edited/udevd.cSat Jan 31 03:08:44 2004+#include <
sys/un.h>
this breaks compilation against klibc. Should udevd run in initramfs? Probably not. Better dont compile it if USE_KLIBC=true
Or provide a sys/un.h in klibc.
Signature · 14 lines
USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Olaf Hering
Quoted 4 lines · Kay Sievers
===
udevd.c1.7 vs edited ==> > ---1.7/udevd.cWed Jan 28 19:52:44 2004
+++edited/udevd.cSat Jan 31 03:08:44 2004+#include <
sys/un.h>this breaks compilation against klibc. Should udevd run in initramfs? Probably not. Better dont compile it if USE_KLIBC=true
Or provide asys/un.hin klibc.
Hey, is this post from today :)
It's already fixed since 6 days.
http://linuxusb.bkbits.net:8080/udev/[email protected]?nav=index.html|ChangeSet@-8d
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Kay Sievers
Quoted 5 lines · Olaf Hering
Quoted 2 lines · Kay Sievers
===
udevd.c1.7 vs edited ==> > > ---1.7/udevd.cWed Jan 28 19:52:44 2004
+++edited/udevd.cSat Jan 31 03:08:44 2004
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
+#include <
sys/un.h>this breaks compilation against klibc. Should udevd run in initramfs? Probably not. Better dont compile it if USE_KLIBC=true
Or provide asys/un.hin klibc.Hey, is this post from today :)
It's already fixed since 6 days.
Not in my copy. Still need this patch.
The install rule needs also an update.
Makefile 2004-02-08 11:04:35.559002703 +0100 renamed from Makefile 2004-02-08 10:55:43.000000000 +0100 +4 -3
@@ -157,6 +157,7 @@ ifeq ($(strip $(USE_KLIBC)),true) -I$(LINUX_INCLUDE_DIR) LIB_OBJS LDFLAGS = --static --nostdlib -nostartfiles -nodefaultlibs + UDEVSENDER UDEVD else WARNINGS += -Wshadow -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
@@ -165,12 +166,13 @@ else CFLAGS += $(WARNINGS) -I$(GCCINCDIR) LIB_OBJS = -lc LDFLAGS + UDEVSENDER= $(SENDER) UDEVD = $(DAEMON) endif CFLAGS += -I$(PWD)/libsysfs -all: $(ROOT) $(SENDER) $(UDEVD) $(HELPER) +all: $(ROOT) $(UDEVSENDER) $(UDEVD) $(HELPER) @extras="$(EXTRAS)" ; for target in $$extras ; do \ echo $$target ; \ $(MAKE) prefix=$(prefix) \
@@ -261,11 +263,11 @@ $(HELPER): $(HEADERS) udevinfo.o $(OBJS) $(LD) $(LDFLAGS) -o $@ $(CRT0) udevinfo.o udev_config.o udevdb.o $(SYSFS) $(TDB) $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $@ -$(DAEMON): udevd.h $(GEN_HEADERS) udevd.o +$(UDEVD): udevd.h $(GEN_HEADERS) udevd.o $(LD) $(LDFLAGS) -o $@ $(CRT0) udevd.o $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $@ -$(SENDER): udevd.h $(GEN_HEADERS) udevsend.o +$(UDEVSENDER): udevd.h $(GEN_HEADERS) udevsend.o $(LD) $(LDFLAGS) -o $@ $(CRT0) udevsend.o $(LIB_OBJS) $(ARCH_LIB_OBJS) $(STRIPCMD) $@
Signature · 14 lines
USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Olaf Hering
Quoted 8 lines · Kay Sievers
Quoted 7 lines · Olaf Hering
Quoted 4 lines · Kay Sievers
===
udevd.c1.7 vs edited ==> > > > ---1.7/udevd.cWed Jan 28 19:52:44 2004
+++edited/udevd.cSat Jan 31 03:08:44 2004+#include <
sys/un.h>
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
this breaks compilation against klibc. Should udevd run in initramfs? Probably not. Better dont compile it if USE_KLIBC=true
Or provide asys/un.hin klibc.Hey, is this post from today :)
It's already fixed since 6 days.Not in my copy.
Huh, you don't have sys/un.h in your copy?
Quoted 2 lines
Still need this patch.
The install rule needs also an update.
But, we do want to compile udevsend with klibc if it is used. udevd will be compiled while "make install" using libc, not nice but it works.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 1 line · Kay Sievers
Huh, you don't have
sys/un.hin your copy?
klibc-0.103.tar.bz2 doesnt have it, but I see it now in the udev bk tree.
Quoted 7 lines
Quoted 3 lines
Still need this patch.
The install rule needs also an update.But, we do want to compile udevsend with klibc if it is used. udevd will be compiled while "make install" using libc, not nice but it works.
yeah, I will just copy the missing file.
Signature · 14 lines
USB is for mice, FireWire is for men! sUse lINUX ag, nÜRNBERG ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel