Systemd/udevd.c

403 lines
9.8 KiB
C
Raw Normal View History

[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
/*
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
* udevd.c - hotplug event serializer
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
*
* Copyright (C) 2004 Kay Sievers <kay.sievers@vrfy.org>
*
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation version 2 of the License.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 675 Mass Ave, Cambridge, MA 02139, USA.
*
*/
#include <pthread.h>
#include <stddef.h>
#include <sys/wait.h>
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
#include <signal.h>
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
#include "list.h"
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
#include "udev.h"
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
#include "udev_version.h"
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
#include "udevd.h"
#include "logging.h"
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
unsigned char logname[42];
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
static pthread_mutex_t msg_lock;
static pthread_mutex_t msg_active_lock;
static pthread_cond_t msg_active;
static pthread_mutex_t exec_lock;
static pthread_mutex_t exec_active_lock;
static pthread_cond_t exec_active;
static pthread_mutex_t running_lock;
static pthread_attr_t thr_attr;
static int expected_seqnum = 0;
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
LIST_HEAD(msg_list);
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
LIST_HEAD(exec_list);
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
LIST_HEAD(running_list);
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
static void msg_dump_queue(void)
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
{
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
struct hotplug_msg *msg;
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
list_for_each_entry(msg, &msg_list, list)
dbg("sequence %d in queue", msg->seqnum);
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
static void msg_dump(struct hotplug_msg *msg)
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
{
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
dbg("sequence %d, '%s', '%s', '%s'",
msg->seqnum, msg->action, msg->devpath, msg->subsystem);
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
static struct hotplug_msg *msg_create(void)
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
{
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
struct hotplug_msg *new_msg;
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
new_msg = malloc(sizeof(struct hotplug_msg));
if (new_msg == NULL) {
dbg("error malloc");
return NULL;
}
return new_msg;
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
}
static void msg_delete(struct hotplug_msg *msg)
{
if (msg != NULL)
free(msg);
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* orders the message in the queue by sequence number */
static void msg_queue_insert(struct hotplug_msg *msg)
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
{
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
struct hotplug_msg *loop_msg;
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* sort message by sequence number into list*/
list_for_each_entry(loop_msg, &msg_list, list)
if (loop_msg->seqnum > msg->seqnum)
break;
list_add_tail(&msg->list, &loop_msg->list);
dbg("queued message seq %d", msg->seqnum);
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* store timestamp of queuing */
msg->queue_time = time(NULL);
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* signal queue activity to manager */
pthread_mutex_lock(&msg_active_lock);
pthread_cond_signal(&msg_active);
pthread_mutex_unlock(&msg_active_lock);
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
return ;
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* forks event and removes event from run queue when finished */
static void *run_threads(void * parm)
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
{
pid_t pid;
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
struct hotplug_msg *msg;
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
msg = parm;
setenv("ACTION", msg->action, 1);
setenv("DEVPATH", msg->devpath, 1);
pid = fork();
switch (pid) {
case 0:
[PATCH] udev - next round of udev event order daemon Here is the next round of udevd/udevsend: udevsend - If the IPC message we send is not catched by a receiver we fork the udevd daemon to process this and the following events udevd - We reorder the events we receive and execute our current udev for every event. If one or more events are missing, we wait 10 seconds and then go ahead in the queue. If the queue is empty and we don't receive any event for the next 30 seconds, the daemon exits. The next incoming event will fork the daemon again. config - The path's to the executable are specified in udevd.h Now they are pointing to the current directory only. I don't like daemons hiding secrets (and mem leaks :)) inside, so I want to try this model. It should be enough logic to get all possible hotplug events executed in the right order. If no event, then no daemon! So everybody should be happy :) Here we see: 1. the daemon fork, 2. the udev work, 3. the 10 sec timeout and the skipped events, 4. the udev work, ..., 5. and the 30 sec timeout and exit. EVENTS: pim:/home/kay/src/udev.kay# test/udevd_test.sh pim:/home/kay/src/udev.kay# SEQNUM=15 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=16 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=17 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=18 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=20 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=21 ./udevsend block LOG: Jan 23 15:35:35 pim udev[11795]: message is still in the ipc queue, starting daemon... Jan 23 15:35:35 pim udev[11799]: configured rule in '/etc/udev/udev.rules' at line 19 applied, 'sda' becomes '%k-flash' Jan 23 15:35:35 pim udev[11799]: creating device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11800]: creating device node '/udev/sdb' Jan 23 15:35:35 pim udev[11804]: creating device node '/udev/sdc' Jan 23 15:35:35 pim udev[11805]: removing device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11808]: removing device node '/udev/sdb' Jan 23 15:35:35 pim udev[11809]: removing device node '/udev/sdc' Jan 23 15:35:45 pim udev[11797]: timeout reached, skip events 7 - 7 Jan 23 15:35:45 pim udev[11811]: creating device node '/udev/sdb' Jan 23 15:35:45 pim udev[11812]: creating device node '/udev/sdc' Jan 23 15:36:01 pim udev[11797]: timeout reached, skip events 10 - 14 Jan 23 15:36:01 pim udev[11814]: creating device node '/udev/sdc' Jan 23 15:36:04 pim udev[11816]: creating device node '/udev/sdc' Jan 23 15:36:12 pim udev[11818]: creating device node '/udev/sdc' Jan 23 15:36:16 pim udev[11820]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11797]: timeout reached, skip events 19 - 19 Jan 23 15:36:38 pim udev[11823]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11824]: creating device node '/udev/sdc' Jan 23 15:37:08 pim udev[11797]: we have nothing to do, so daemon exits...
2004-01-24 06:25:17 +01:00
/* child */
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
execl(UDEV_BIN, "udev", msg->subsystem, NULL);
[PATCH] udev - next round of udev event order daemon Here is the next round of udevd/udevsend: udevsend - If the IPC message we send is not catched by a receiver we fork the udevd daemon to process this and the following events udevd - We reorder the events we receive and execute our current udev for every event. If one or more events are missing, we wait 10 seconds and then go ahead in the queue. If the queue is empty and we don't receive any event for the next 30 seconds, the daemon exits. The next incoming event will fork the daemon again. config - The path's to the executable are specified in udevd.h Now they are pointing to the current directory only. I don't like daemons hiding secrets (and mem leaks :)) inside, so I want to try this model. It should be enough logic to get all possible hotplug events executed in the right order. If no event, then no daemon! So everybody should be happy :) Here we see: 1. the daemon fork, 2. the udev work, 3. the 10 sec timeout and the skipped events, 4. the udev work, ..., 5. and the 30 sec timeout and exit. EVENTS: pim:/home/kay/src/udev.kay# test/udevd_test.sh pim:/home/kay/src/udev.kay# SEQNUM=15 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=16 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=17 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=18 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=20 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=21 ./udevsend block LOG: Jan 23 15:35:35 pim udev[11795]: message is still in the ipc queue, starting daemon... Jan 23 15:35:35 pim udev[11799]: configured rule in '/etc/udev/udev.rules' at line 19 applied, 'sda' becomes '%k-flash' Jan 23 15:35:35 pim udev[11799]: creating device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11800]: creating device node '/udev/sdb' Jan 23 15:35:35 pim udev[11804]: creating device node '/udev/sdc' Jan 23 15:35:35 pim udev[11805]: removing device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11808]: removing device node '/udev/sdb' Jan 23 15:35:35 pim udev[11809]: removing device node '/udev/sdc' Jan 23 15:35:45 pim udev[11797]: timeout reached, skip events 7 - 7 Jan 23 15:35:45 pim udev[11811]: creating device node '/udev/sdb' Jan 23 15:35:45 pim udev[11812]: creating device node '/udev/sdc' Jan 23 15:36:01 pim udev[11797]: timeout reached, skip events 10 - 14 Jan 23 15:36:01 pim udev[11814]: creating device node '/udev/sdc' Jan 23 15:36:04 pim udev[11816]: creating device node '/udev/sdc' Jan 23 15:36:12 pim udev[11818]: creating device node '/udev/sdc' Jan 23 15:36:16 pim udev[11820]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11797]: timeout reached, skip events 19 - 19 Jan 23 15:36:38 pim udev[11823]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11824]: creating device node '/udev/sdc' Jan 23 15:37:08 pim udev[11797]: we have nothing to do, so daemon exits...
2004-01-24 06:25:17 +01:00
dbg("exec of child failed");
exit(1);
break;
case -1:
[PATCH] udev - next round of udev event order daemon Here is the next round of udevd/udevsend: udevsend - If the IPC message we send is not catched by a receiver we fork the udevd daemon to process this and the following events udevd - We reorder the events we receive and execute our current udev for every event. If one or more events are missing, we wait 10 seconds and then go ahead in the queue. If the queue is empty and we don't receive any event for the next 30 seconds, the daemon exits. The next incoming event will fork the daemon again. config - The path's to the executable are specified in udevd.h Now they are pointing to the current directory only. I don't like daemons hiding secrets (and mem leaks :)) inside, so I want to try this model. It should be enough logic to get all possible hotplug events executed in the right order. If no event, then no daemon! So everybody should be happy :) Here we see: 1. the daemon fork, 2. the udev work, 3. the 10 sec timeout and the skipped events, 4. the udev work, ..., 5. and the 30 sec timeout and exit. EVENTS: pim:/home/kay/src/udev.kay# test/udevd_test.sh pim:/home/kay/src/udev.kay# SEQNUM=15 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=16 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=17 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=18 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=20 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=21 ./udevsend block LOG: Jan 23 15:35:35 pim udev[11795]: message is still in the ipc queue, starting daemon... Jan 23 15:35:35 pim udev[11799]: configured rule in '/etc/udev/udev.rules' at line 19 applied, 'sda' becomes '%k-flash' Jan 23 15:35:35 pim udev[11799]: creating device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11800]: creating device node '/udev/sdb' Jan 23 15:35:35 pim udev[11804]: creating device node '/udev/sdc' Jan 23 15:35:35 pim udev[11805]: removing device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11808]: removing device node '/udev/sdb' Jan 23 15:35:35 pim udev[11809]: removing device node '/udev/sdc' Jan 23 15:35:45 pim udev[11797]: timeout reached, skip events 7 - 7 Jan 23 15:35:45 pim udev[11811]: creating device node '/udev/sdb' Jan 23 15:35:45 pim udev[11812]: creating device node '/udev/sdc' Jan 23 15:36:01 pim udev[11797]: timeout reached, skip events 10 - 14 Jan 23 15:36:01 pim udev[11814]: creating device node '/udev/sdc' Jan 23 15:36:04 pim udev[11816]: creating device node '/udev/sdc' Jan 23 15:36:12 pim udev[11818]: creating device node '/udev/sdc' Jan 23 15:36:16 pim udev[11820]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11797]: timeout reached, skip events 19 - 19 Jan 23 15:36:38 pim udev[11823]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11824]: creating device node '/udev/sdc' Jan 23 15:37:08 pim udev[11797]: we have nothing to do, so daemon exits...
2004-01-24 06:25:17 +01:00
dbg("fork of child failed");
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
goto exit;
default:
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* wait for exit of child */
dbg("==> exec seq %d [%d] working at '%s'",
msg->seqnum, pid, msg->devpath);
wait(NULL);
dbg("<== exec seq %d came back", msg->seqnum);
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
exit:
/* remove event from run list */
pthread_mutex_lock(&running_lock);
list_del_init(&msg->list);
pthread_mutex_unlock(&running_lock);
msg_delete(msg);
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* signal queue activity to exec manager */
pthread_mutex_lock(&exec_active_lock);
pthread_cond_signal(&exec_active);
pthread_mutex_unlock(&exec_active_lock);
pthread_exit(0);
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* returns already running task with devpath */
static struct hotplug_msg *running_with_devpath(struct hotplug_msg *msg)
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
{
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
struct hotplug_msg *loop_msg;
struct hotplug_msg *tmp_msg;
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
list_for_each_entry_safe(loop_msg, tmp_msg, &running_list, list)
if (strncmp(loop_msg->devpath, msg->devpath, sizeof(loop_msg->devpath)) == 0)
return loop_msg;
return NULL;
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* queue management executes the events and delays events for the same devpath */
static void *exec_queue_manager(void * parm)
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
{
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
struct hotplug_msg *loop_msg;
struct hotplug_msg *tmp_msg;
struct hotplug_msg *msg;
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
pthread_t run_tid;
while (1) {
pthread_mutex_lock(&exec_lock);
list_for_each_entry_safe(loop_msg, tmp_msg, &exec_list, list) {
msg = running_with_devpath(loop_msg);
if (msg == NULL) {
/* move event to run list */
pthread_mutex_lock(&running_lock);
list_move_tail(&loop_msg->list, &running_list);
pthread_mutex_unlock(&running_lock);
pthread_create(&run_tid, &thr_attr, run_threads, (void *) loop_msg);
dbg("moved seq %d to running list", loop_msg->seqnum);
} else {
dbg("delay seq %d, cause seq %d already working on '%s'",
loop_msg->seqnum, msg->seqnum, msg->devpath);
}
}
pthread_mutex_unlock(&exec_lock);
/* wait for activation, new events or childs coming back */
pthread_mutex_lock(&exec_active_lock);
pthread_cond_wait(&exec_active, &exec_active_lock);
pthread_mutex_unlock(&exec_active_lock);
}
}
static void exec_queue_activate(void)
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
{
pthread_mutex_lock(&exec_active_lock);
pthread_cond_signal(&exec_active);
pthread_mutex_unlock(&exec_active_lock);
}
/* move message from incoming to exec queue */
static void msg_move_exec(struct list_head *head)
{
list_move_tail(head, &exec_list);
exec_queue_activate();
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* queue management thread handles the timeouts and dispatches the events */
static void *msg_queue_manager(void * parm)
{
struct hotplug_msg *loop_msg;
struct hotplug_msg *tmp_msg;
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
time_t msg_age = 0;
struct timespec tv;
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
while (1) {
dbg("msg queue manager, next expected is %d", expected_seqnum);
pthread_mutex_lock(&msg_lock);
pthread_mutex_lock(&exec_lock);
recheck:
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
list_for_each_entry_safe(loop_msg, tmp_msg, &msg_list, list) {
/* move event with expected sequence to the exec list */
if (loop_msg->seqnum == expected_seqnum) {
msg_move_exec(&loop_msg->list);
expected_seqnum++;
dbg("moved seq %d to exec, next expected is %d",
loop_msg->seqnum, expected_seqnum);
continue;
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* move event with expired timeout to the exec list */
msg_age = time(NULL) - loop_msg->queue_time;
if (msg_age > EVENT_TIMEOUT_SEC-1) {
msg_move_exec(&loop_msg->list);
expected_seqnum = loop_msg->seqnum+1;
dbg("moved seq %d to exec, reset next expected to %d",
loop_msg->seqnum, expected_seqnum);
goto recheck;
} else {
break;
}
}
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
msg_dump_queue();
pthread_mutex_unlock(&exec_lock);
pthread_mutex_unlock(&msg_lock);
[PATCH] udevd - next round of fixes 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 :) 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
2004-01-28 03:57:36 +01:00
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* wait until queue gets active or next message timeout expires */
pthread_mutex_lock(&msg_active_lock);
if (list_empty(&msg_list) == 0) {
tv.tv_sec = time(NULL) + EVENT_TIMEOUT_SEC - msg_age;
tv.tv_nsec = 0;
dbg("next event expires in %li seconds",
EVENT_TIMEOUT_SEC - msg_age);
pthread_cond_timedwait(&msg_active, &msg_active_lock, &tv);
} else {
pthread_cond_wait(&msg_active, &msg_active_lock);
}
pthread_mutex_unlock(&msg_active_lock);
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
}
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* every connect creates a thread which gets the msg, queues it and exits */
static void *client_threads(void * parm)
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
{
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
int sock;
struct hotplug_msg *msg;
int retval;
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
sock = (int) parm;
msg = msg_create();
if (msg == NULL) {
dbg("unable to store message");
goto exit;
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
retval = recv(sock, msg, sizeof(struct hotplug_msg), 0);
if (retval < 0) {
dbg("unable to receive message");
goto exit;
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
if (strncmp(msg->magic, UDEV_MAGIC, sizeof(UDEV_MAGIC)) != 0 ) {
dbg("message magic '%s' doesn't match, ignore it", msg->magic);
msg_delete(msg);
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
goto exit;
}
/* if no seqnum is given, we move straight to exec queue */
if (msg->seqnum == 0) {
pthread_mutex_lock(&exec_lock);
list_add(&msg->list, &exec_list);
exec_queue_activate();
pthread_mutex_unlock(&exec_lock);
} else {
pthread_mutex_lock(&msg_lock);
msg_queue_insert(msg);
pthread_mutex_unlock(&msg_lock);
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
exit:
close(sock);
pthread_exit(0);
}
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
static void sig_handler(int signum)
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
{
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
switch (signum) {
case SIGINT:
case SIGTERM:
exit(20 + signum);
break;
default:
dbg("unhandled signal");
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
}
[PATCH] udev - next round of udev event order daemon Here is the next round of udevd/udevsend: udevsend - If the IPC message we send is not catched by a receiver we fork the udevd daemon to process this and the following events udevd - We reorder the events we receive and execute our current udev for every event. If one or more events are missing, we wait 10 seconds and then go ahead in the queue. If the queue is empty and we don't receive any event for the next 30 seconds, the daemon exits. The next incoming event will fork the daemon again. config - The path's to the executable are specified in udevd.h Now they are pointing to the current directory only. I don't like daemons hiding secrets (and mem leaks :)) inside, so I want to try this model. It should be enough logic to get all possible hotplug events executed in the right order. If no event, then no daemon! So everybody should be happy :) Here we see: 1. the daemon fork, 2. the udev work, 3. the 10 sec timeout and the skipped events, 4. the udev work, ..., 5. and the 30 sec timeout and exit. EVENTS: pim:/home/kay/src/udev.kay# test/udevd_test.sh pim:/home/kay/src/udev.kay# SEQNUM=15 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=16 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=17 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=18 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=20 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=21 ./udevsend block LOG: Jan 23 15:35:35 pim udev[11795]: message is still in the ipc queue, starting daemon... Jan 23 15:35:35 pim udev[11799]: configured rule in '/etc/udev/udev.rules' at line 19 applied, 'sda' becomes '%k-flash' Jan 23 15:35:35 pim udev[11799]: creating device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11800]: creating device node '/udev/sdb' Jan 23 15:35:35 pim udev[11804]: creating device node '/udev/sdc' Jan 23 15:35:35 pim udev[11805]: removing device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11808]: removing device node '/udev/sdb' Jan 23 15:35:35 pim udev[11809]: removing device node '/udev/sdc' Jan 23 15:35:45 pim udev[11797]: timeout reached, skip events 7 - 7 Jan 23 15:35:45 pim udev[11811]: creating device node '/udev/sdb' Jan 23 15:35:45 pim udev[11812]: creating device node '/udev/sdc' Jan 23 15:36:01 pim udev[11797]: timeout reached, skip events 10 - 14 Jan 23 15:36:01 pim udev[11814]: creating device node '/udev/sdc' Jan 23 15:36:04 pim udev[11816]: creating device node '/udev/sdc' Jan 23 15:36:12 pim udev[11818]: creating device node '/udev/sdc' Jan 23 15:36:16 pim udev[11820]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11797]: timeout reached, skip events 19 - 19 Jan 23 15:36:38 pim udev[11823]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11824]: creating device node '/udev/sdc' Jan 23 15:37:08 pim udev[11797]: we have nothing to do, so daemon exits...
2004-01-24 06:25:17 +01:00
}
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
[PATCH] udev - next round of udev event order daemon Here is the next round of udevd/udevsend: udevsend - If the IPC message we send is not catched by a receiver we fork the udevd daemon to process this and the following events udevd - We reorder the events we receive and execute our current udev for every event. If one or more events are missing, we wait 10 seconds and then go ahead in the queue. If the queue is empty and we don't receive any event for the next 30 seconds, the daemon exits. The next incoming event will fork the daemon again. config - The path's to the executable are specified in udevd.h Now they are pointing to the current directory only. I don't like daemons hiding secrets (and mem leaks :)) inside, so I want to try this model. It should be enough logic to get all possible hotplug events executed in the right order. If no event, then no daemon! So everybody should be happy :) Here we see: 1. the daemon fork, 2. the udev work, 3. the 10 sec timeout and the skipped events, 4. the udev work, ..., 5. and the 30 sec timeout and exit. EVENTS: pim:/home/kay/src/udev.kay# test/udevd_test.sh pim:/home/kay/src/udev.kay# SEQNUM=15 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=16 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=17 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=18 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=20 ./udevsend block pim:/home/kay/src/udev.kay# SEQNUM=21 ./udevsend block LOG: Jan 23 15:35:35 pim udev[11795]: message is still in the ipc queue, starting daemon... Jan 23 15:35:35 pim udev[11799]: configured rule in '/etc/udev/udev.rules' at line 19 applied, 'sda' becomes '%k-flash' Jan 23 15:35:35 pim udev[11799]: creating device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11800]: creating device node '/udev/sdb' Jan 23 15:35:35 pim udev[11804]: creating device node '/udev/sdc' Jan 23 15:35:35 pim udev[11805]: removing device node '/udev/sda-flash' Jan 23 15:35:35 pim udev[11808]: removing device node '/udev/sdb' Jan 23 15:35:35 pim udev[11809]: removing device node '/udev/sdc' Jan 23 15:35:45 pim udev[11797]: timeout reached, skip events 7 - 7 Jan 23 15:35:45 pim udev[11811]: creating device node '/udev/sdb' Jan 23 15:35:45 pim udev[11812]: creating device node '/udev/sdc' Jan 23 15:36:01 pim udev[11797]: timeout reached, skip events 10 - 14 Jan 23 15:36:01 pim udev[11814]: creating device node '/udev/sdc' Jan 23 15:36:04 pim udev[11816]: creating device node '/udev/sdc' Jan 23 15:36:12 pim udev[11818]: creating device node '/udev/sdc' Jan 23 15:36:16 pim udev[11820]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11797]: timeout reached, skip events 19 - 19 Jan 23 15:36:38 pim udev[11823]: creating device node '/udev/sdc' Jan 23 15:36:38 pim udev[11824]: creating device node '/udev/sdc' Jan 23 15:37:08 pim udev[11797]: we have nothing to do, so daemon exits...
2004-01-24 06:25:17 +01:00
int main(int argc, char *argv[])
{
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
int ssock;
int csock;
struct sockaddr_un saddr;
struct sockaddr_un caddr;
socklen_t addrlen;
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
socklen_t clen;
pthread_t cli_tid;
pthread_t mgr_msg_tid;
pthread_t mgr_exec_tid;
int retval;
init_logging("udevd");
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
signal(SIGINT, sig_handler);
signal(SIGTERM, sig_handler);
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
memset(&saddr, 0x00, sizeof(saddr));
saddr.sun_family = AF_LOCAL;
/* use abstract namespace for socket path */
strcpy(&saddr.sun_path[1], UDEVD_SOCK_PATH);
addrlen = offsetof(struct sockaddr_un, sun_path) + strlen(saddr.sun_path+1) + 1;
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
ssock = socket(AF_LOCAL, SOCK_STREAM, 0);
if (ssock == -1) {
dbg("error getting socket");
exit(1);
}
retval = bind(ssock, &saddr, addrlen);
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
if (retval < 0) {
dbg("bind failed\n");
goto exit;
}
retval = listen(ssock, SOMAXCONN);
if (retval < 0) {
dbg("listen failed\n");
goto exit;
}
pthread_mutex_init(&msg_lock, NULL);
pthread_mutex_init(&msg_active_lock, NULL);
pthread_mutex_init(&exec_lock, NULL);
pthread_mutex_init(&exec_active_lock, NULL);
pthread_mutex_init(&running_lock, NULL);
/* 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);
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
/* init queue management */
pthread_create(&mgr_msg_tid, &thr_attr, msg_queue_manager, NULL);
pthread_create(&mgr_exec_tid, &thr_attr, exec_queue_manager, NULL);
clen = sizeof(caddr);
/* main loop */
while (1) {
csock = accept(ssock, &caddr, &clen);
if (csock < 0) {
dbg("client accept failed\n");
continue;
[PATCH] udevd - cleanup and better timeout handling On Thu, Jan 29, 2004 at 04:55:11PM +0100, Kay Sievers wrote: > On Thu, Jan 29, 2004 at 02:56:25AM +0100, Kay Sievers wrote: > > On Wed, Jan 28, 2004 at 10:47:36PM +0100, Kay Sievers wrote: > > > Oh, couldn't resist to try threads. > > > It's a multithreaded udevd that communicates through a localhost socket. > > > The message includes a magic with the udev version, so we don't accept > > > older udevsend's. > > > > > > No need for locking, cause we can't bind two sockets on the same address. > > > The daemon tries to connect and if it fails it starts the daemon. > > > > > > We create a thread for every incoming connection, handle over the socket, > > > sort the messages in the global message queue and exit the thread. > > > Huh, that was easy with threads :) > > > > > > With the addition of a message we wakeup the queue manager thread and > > > handle timeouts or move the message to the global exec list. This wakes > > > up the exec list manager who looks if a process is already running for this > > > device path. > > > If yes, the exec is delayed otherwise we create a thread that execs udev. > > > n the background. With the return of udev we free the message and wakeup > > > the exec list manager to look if something is pending. > > > > > > It is just a quick shot, cause I couldn't solve the problems with fork an > > > scheduling and I wanted to see if I'm to stupid :) > > > But if anybody with a better idea or more experience with I/O scheduling > > > we may go another way. The remaining problem is that klibc doesn't support > > > threads. > > > > > > By now, we don't exec anything, it's just a sleep 3 for every exec, > > > but you can see the queue management by watching syslog and do: > > > > > > DEVPATH=/abc ACTION=add SEQNUM=0 ./udevsend /abc > > Next version, switched to unix domain sockets. Next cleaned up version. Hey, nobody wants to try it :) Works for me, It's funny if I connect/disconnect my 4in1-usb-flash-reader every two seconds. The 2.6 usb rocks! I can connect/diconnect a hub with 3 devices plugged in every second and don't run into any problem but a _very_ big udevd queue.
2004-02-01 18:12:36 +01:00
}
pthread_create(&cli_tid, &thr_attr, client_threads, (void *) csock);
}
exit:
close(ssock);
exit(1);
[PATCH] spilt udev into pieces On Thu, Jan 22, 2004 at 01:27:45AM +0100, Kay Sievers wrote: > On Wed, Jan 21, 2004 at 02:38:25PM +0100, Kay Sievers wrote: > > On Thu, Jan 15, 2004 at 01:45:10PM -0800, Greg KH wrote: > > > On Thu, Jan 15, 2004 at 10:36:25PM +0800, Ling, Xiaofeng wrote: > > > > Hi, Greg > > > > I wrote a simple implementation for the two pieces > > > > of send and receive hotplug event, > > > > use a message queue and a list for the out of order > > > > hotplug event. It also has a timeout timer of 3 seconds. > > > > They are now separate program. the file nseq is the test script. > > > > Could you have a look to see wether it is feasible? > > > > If so, I'll continue to merge with udev. > > > > > > Yes, very nice start. Please continue on. > > > > > > One minor comment, please stick with the kernel coding style when you > > > are writing new code for udev. > > > > I took the code from Xiaofeng, cleaned the whitespace, renamed some bits, > > tweaked the debugging, added the udev exec and created a patch for the current tree. > > > > It seems functional now, by simply executing our current udev (dirty hack). > > It reorders the incoming events and if one is missing it delays the > > execution of the following ones up to a maximum of 10 seconds. > > > > Test script is included, but you can't mix hotplug sequence numbers and > > test script numbers, it will result in waiting for the missing numbers :) > > Hey, nobody want's to play with me? > So here I'm chatting with myself :) > > This is the next version with signal handling for resetting the expected > signal number. I changed the behaviour of the timeout to skip all > missing events at once and to proceed with the next event in the queue. > > So it's now possible to use the test script at any time, cause it resets > the daemon, if real hotplug event coming in later all missing nimbers will > be skipped after a timeout of 10 seconds and the queued events are applied. Here is the next updated updated version to apply to the lastet udev. I've added infrastructure for getting the state of the IPC queue in the sender and set the program to exec by the daemon. Also the magic key id is replaced by the usual key generation by path/nr. It looks promising, I use it on my machine and my 4in1 USB-flash-reader connect/disconnect emits the events "randomly" but udevd is able to reorder it and calls our normal udev in the right order.
2004-01-23 09:28:57 +01:00
}