[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 11:28:57 +03:00
/*
2005-08-09 21:45:08 +04:00
* udevd . c - event listener and 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 11:28:57 +03:00
*
2006-08-05 15:22:44 +04:00
* Copyright ( C ) 2004 - 2006 Kay Sievers < kay . sievers @ vrfy . org >
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
* Copyright ( C ) 2004 Chris Friesen < chris_friesen @ sympatico . ca >
[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 11:28:57 +03:00
*
*
* 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 0213 9 , USA .
*
*/
2004-01-27 05:19:33 +03:00
# include <stddef.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 11:28:57 +03:00
# include <signal.h>
# include <unistd.h>
# include <errno.h>
# include <stdio.h>
# include <stdlib.h>
# include <string.h>
2005-01-17 02:53:08 +03:00
# include <ctype.h>
# include <dirent.h>
# include <fcntl.h>
2005-08-15 13:57:04 +04:00
# include <syslog.h>
2005-11-07 04:22:44 +03:00
# include <time.h>
2005-03-10 02:58:01 +03:00
# include <sys/select.h>
# include <sys/wait.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 20:12:36 +03:00
# include <sys/types.h>
# include <sys/socket.h>
# include <sys/un.h>
2004-10-14 09:37:59 +04:00
# include <sys/stat.h>
2005-10-27 23:04:38 +04:00
# include <sys/ioctl.h>
2005-11-12 07:09:34 +03:00
# include <linux/types.h>
2005-06-05 06:38:10 +04:00
# include <linux/netlink.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 11:28:57 +03:00
# include "udev.h"
2005-10-27 23:04:38 +04:00
# include "udev_rules.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 11:28:57 +03:00
# include "udevd.h"
2006-01-09 23:18:00 +03:00
static struct udev_rules rules ;
2005-06-05 06:41:09 +04:00
static int udevd_sock ;
2005-06-16 03:58:47 +04:00
static int uevent_netlink_sock ;
2005-10-27 23:04:38 +04:00
static int inotify_fd ;
2005-01-17 02:53:08 +03:00
static pid_t sid ;
2004-11-12 08:18:28 +03:00
2005-08-28 22:25:37 +04:00
static int signal_pipe [ 2 ] = { - 1 , - 1 } ;
2004-10-19 15:37:30 +04:00
static volatile int sigchilds_waiting ;
2005-08-08 07:07:36 +04:00
static volatile int udev_exit ;
2005-10-27 23:04:38 +04:00
static volatile int reload_config ;
2004-04-01 11:03:07 +04:00
static int run_exec_q ;
2005-06-05 06:41:09 +04:00
static int stop_exec_q ;
2005-06-05 06:53:17 +04:00
static int max_childs ;
static int max_childs_running ;
2005-10-27 22:32:07 +04:00
static char udev_log [ 32 ] ;
2005-08-15 13:57:04 +04:00
static LIST_HEAD ( exec_list ) ;
static LIST_HEAD ( running_list ) ;
2005-06-05 06:53:17 +04: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 11:28:57 +03:00
2005-03-06 12:15:51 +03:00
# ifdef USE_LOG
2005-10-27 23:04:38 +04:00
void log_message ( int priority , const char * format , . . . )
2004-02-12 09:10:26 +03:00
{
2005-03-27 03:11:03 +04:00
va_list args ;
if ( priority > udev_log_priority )
return ;
2004-02-13 05:57:06 +03:00
va_start ( args , format ) ;
2005-03-27 03:11:03 +04:00
vsyslog ( priority , format , args ) ;
2004-02-13 05:57:06 +03:00
va_end ( args ) ;
2004-02-12 09:10:26 +03:00
}
2004-02-13 05:57:06 +03:00
# endif
2004-02-12 09:10:26 +03:00
2005-10-27 23:04:38 +04:00
static void asmlinkage udev_event_sig_handler ( int signum )
{
if ( signum = = SIGALRM )
exit ( 1 ) ;
}
2006-08-05 15:22:44 +04:00
static int udev_event_process ( struct udevd_uevent_msg * msg )
2005-10-27 23:04:38 +04:00
{
struct sigaction act ;
2006-01-09 23:18:00 +03:00
struct udevice * udev ;
2005-10-27 23:04:38 +04:00
int i ;
int retval ;
/* set signal handlers */
memset ( & act , 0x00 , sizeof ( act ) ) ;
act . sa_handler = ( void ( * ) ( int ) ) udev_event_sig_handler ;
sigemptyset ( & act . sa_mask ) ;
act . sa_flags = 0 ;
sigaction ( SIGALRM , & act , NULL ) ;
2006-03-16 12:46:30 +03:00
/* reset to default */
act . sa_handler = SIG_DFL ;
sigaction ( SIGINT , & act , NULL ) ;
sigaction ( SIGTERM , & act , NULL ) ;
sigaction ( SIGCHLD , & act , NULL ) ;
sigaction ( SIGHUP , & act , NULL ) ;
2005-10-27 23:04:38 +04:00
/* trigger timeout to prevent hanging processes */
alarm ( UDEV_ALARM_TIMEOUT ) ;
2006-01-09 23:18:00 +03:00
/* reconstruct event environment from message */
2005-10-27 23:04:38 +04:00
for ( i = 0 ; msg - > envp [ i ] ; i + + )
putenv ( msg - > envp [ i ] ) ;
2006-01-09 23:18:00 +03:00
udev = udev_device_init ( ) ;
if ( udev = = NULL )
return - 1 ;
strlcpy ( udev - > action , msg - > action , sizeof ( udev - > action ) ) ;
sysfs_device_set_values ( udev - > dev , msg - > devpath , msg - > subsystem ) ;
udev - > devt = msg - > devt ;
retval = udev_device_event ( & rules , udev ) ;
2005-10-27 23:04:38 +04:00
/* run programs collected by RUN-key*/
2006-01-25 04:21:07 +03:00
if ( retval = = 0 & & ! udev - > ignore_device & & udev_run ) {
2006-01-09 23:18:00 +03:00
struct name_entry * name_loop ;
2006-01-25 04:21:07 +03:00
dbg ( " executing run list " ) ;
2006-01-09 23:18:00 +03:00
list_for_each_entry ( name_loop , & udev - > run_list , node ) {
2005-10-27 23:04:38 +04:00
if ( strncmp ( name_loop - > name , " socket: " , strlen ( " socket: " ) ) = = 0 )
2006-04-06 22:56:15 +04:00
pass_env_to_socket ( & name_loop - > name [ strlen ( " socket: " ) ] , udev - > dev - > devpath , udev - > action ) ;
2006-01-24 22:10:48 +03:00
else {
char program [ PATH_SIZE ] ;
strlcpy ( program , name_loop - > name , sizeof ( program ) ) ;
2006-01-25 03:28:31 +03:00
udev_rules_apply_format ( udev , program , sizeof ( program ) ) ;
2006-01-24 22:10:48 +03:00
if ( run_program ( program , udev - > dev - > subsystem , NULL , 0 , NULL ,
2005-11-16 04:06:46 +03:00
( udev_log_priority > = LOG_INFO ) ) )
retval = - 1 ;
2006-01-24 22:10:48 +03:00
}
2005-10-27 23:04:38 +04:00
}
}
2006-01-09 23:18:00 +03:00
udev_device_cleanup ( udev ) ;
2005-11-16 04:06:46 +03:00
return retval ;
2005-10-27 23:04:38 +04:00
}
2005-11-16 06:12:53 +03:00
enum event_state {
EVENT_QUEUED ,
EVENT_FINISHED ,
EVENT_FAILED ,
} ;
2006-08-05 15:22:44 +04:00
static void export_event_state ( struct udevd_uevent_msg * msg , enum event_state state )
2005-11-16 06:12:53 +03:00
{
char filename [ PATH_SIZE ] ;
char filename_failed [ PATH_SIZE ] ;
char target [ PATH_SIZE ] ;
size_t start , end , i ;
2006-08-05 15:22:44 +04:00
struct udevd_uevent_msg * loop_msg ;
2005-11-16 06:12:53 +03:00
/* add location of queue files */
strlcpy ( filename , udev_root , sizeof ( filename ) ) ;
strlcat ( filename , " / " , sizeof ( filename ) ) ;
start = strlcat ( filename , EVENT_QUEUE_DIR , sizeof ( filename ) ) ;
end = strlcat ( filename , msg - > devpath , sizeof ( filename ) ) ;
if ( end > sizeof ( filename ) )
end = sizeof ( filename ) ;
/* replace '/' to transform path into a filename */
for ( i = start + 1 ; i < end ; i + + )
if ( filename [ i ] = = ' / ' )
filename [ i ] = PATH_TO_NAME_CHAR ;
/* add location of failed files */
strlcpy ( filename_failed , udev_root , sizeof ( filename_failed ) ) ;
strlcat ( filename_failed , " / " , sizeof ( filename_failed ) ) ;
start = strlcat ( filename_failed , EVENT_FAILED_DIR , sizeof ( filename_failed ) ) ;
end = strlcat ( filename_failed , msg - > devpath , sizeof ( filename_failed ) ) ;
if ( end > sizeof ( filename_failed ) )
end = sizeof ( filename_failed ) ;
/* replace '/' to transform path into a filename */
for ( i = start + 1 ; i < end ; i + + )
if ( filename_failed [ i ] = = ' / ' )
filename_failed [ i ] = PATH_TO_NAME_CHAR ;
switch ( state ) {
case EVENT_QUEUED :
unlink ( filename_failed ) ;
2005-11-22 17:49:49 +03:00
delete_path ( filename_failed ) ;
2005-11-16 06:12:53 +03:00
strlcpy ( target , sysfs_path , sizeof ( target ) ) ;
strlcat ( target , msg - > devpath , sizeof ( target ) ) ;
create_path ( filename ) ;
symlink ( target , filename ) ;
return ;
case EVENT_FINISHED :
2005-11-22 17:49:49 +03:00
case EVENT_FAILED :
2005-11-16 06:12:53 +03:00
unlink ( filename_failed ) ;
2005-11-22 17:49:49 +03:00
delete_path ( filename_failed ) ;
2005-11-16 06:12:53 +03:00
2005-11-22 17:49:49 +03:00
/* don't remove, if events for the same path are still pending */
2005-11-16 06:12:53 +03:00
list_for_each_entry ( loop_msg , & running_list , node )
if ( loop_msg - > devpath & & strcmp ( loop_msg - > devpath , msg - > devpath ) = = 0 )
return ;
2005-11-22 17:49:49 +03:00
2006-02-23 22:10:49 +03:00
list_for_each_entry ( loop_msg , & exec_list , node )
if ( loop_msg - > devpath & & strcmp ( loop_msg - > devpath , msg - > devpath ) = = 0 )
return ;
2005-11-22 17:49:49 +03:00
/* move failed events to the failed directory */
if ( state = = EVENT_FAILED ) {
create_path ( filename_failed ) ;
rename ( filename , filename_failed ) ;
} else {
unlink ( filename ) ;
}
/* clean up the queue directory */
delete_path ( filename ) ;
2005-11-16 06:12:53 +03:00
return ;
}
}
2006-08-05 15:22:44 +04:00
static void msg_queue_delete ( struct udevd_uevent_msg * msg )
2005-11-07 16:10:09 +03:00
{
list_del ( & msg - > node ) ;
2005-11-16 06:12:53 +03:00
/* mark as failed, if add event returns non-zero */
if ( msg - > exitstatus & & strcmp ( msg - > action , " add " ) = = 0 )
export_event_state ( msg , EVENT_FAILED ) ;
else
export_event_state ( msg , EVENT_FINISHED ) ;
2005-11-07 16:10:09 +03:00
free ( msg ) ;
}
2006-08-05 15:22:44 +04:00
static void udev_event_run ( struct udevd_uevent_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 11:28:57 +03:00
{
2004-01-23 15:01:09 +03:00
pid_t pid ;
2005-11-16 04:06:46 +03:00
int retval ;
2004-01-23 15:01:09 +03:00
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 08:25:17 +03:00
/* child */
2005-11-04 07:25:15 +03:00
close ( uevent_netlink_sock ) ;
close ( udevd_sock ) ;
2006-04-25 20:50:56 +04:00
if ( inotify_fd > = 0 )
2005-10-27 23:04:38 +04:00
close ( inotify_fd ) ;
close ( signal_pipe [ READ_END ] ) ;
close ( signal_pipe [ WRITE_END ] ) ;
2004-11-23 05:30:13 +03:00
logging_close ( ) ;
2005-10-27 23:04:38 +04:00
logging_init ( " udevd-event " ) ;
2005-01-17 02:53:08 +03:00
setpriority ( PRIO_PROCESS , 0 , UDEV_PRIORITY ) ;
2006-07-25 16:45:09 +04:00
2005-11-16 04:06:46 +03:00
retval = udev_event_process ( msg ) ;
2005-10-27 23:04:38 +04:00
info ( " seq %llu finished " , msg - > seqnum ) ;
logging_close ( ) ;
2005-11-16 04:06:46 +03:00
if ( retval )
exit ( 1 ) ;
2005-10-27 23:04:38 +04:00
exit ( 0 ) ;
2004-01-23 15:01:09 +03:00
case - 1 :
2005-11-07 20:44:18 +03:00
err ( " fork of child failed: %s " , strerror ( errno ) ) ;
2005-07-06 04:02:05 +04:00
msg_queue_delete ( msg ) ;
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
break ;
2004-01-23 15:01:09 +03:00
default :
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
/* get SIGCHLD in main loop */
2005-08-15 13:57:04 +04:00
info ( " seq %llu forked, pid [%d], '%s' '%s', %ld seconds old " ,
2005-11-07 04:22:44 +03:00
msg - > seqnum , pid , msg - > action , msg - > subsystem , time ( NULL ) - msg - > queue_time ) ;
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
msg - > pid = pid ;
2004-01-23 15:01:09 +03: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 11:28:57 +03:00
}
2006-08-05 15:22:44 +04:00
static void msg_queue_insert ( struct udevd_uevent_msg * msg )
2005-11-07 16:10:09 +03:00
{
2006-04-05 02:08:10 +04:00
char filename [ PATH_SIZE ] ;
int fd ;
2005-11-07 16:10:09 +03:00
msg - > queue_time = time ( NULL ) ;
2006-04-05 02:08:10 +04:00
strlcpy ( filename , udev_root , sizeof ( filename ) ) ;
strlcat ( filename , " / " EVENT_SEQNUM , sizeof ( filename ) ) ;
fd = open ( filename , O_WRONLY | O_TRUNC | O_CREAT , 0644 ) ;
2006-04-25 20:50:56 +04:00
if ( fd > = 0 ) {
2006-04-05 02:08:10 +04:00
char str [ 32 ] ;
int len ;
len = sprintf ( str , " %llu \n " , msg - > seqnum ) ;
write ( fd , str , len ) ;
close ( fd ) ;
}
2005-11-07 16:10:09 +03:00
2005-11-16 06:12:53 +03:00
export_event_state ( msg , EVENT_QUEUED ) ;
2005-11-07 16:10:09 +03:00
/* run all events with a timeout set immediately */
if ( msg - > timeout ! = 0 ) {
list_add_tail ( & msg - > node , & running_list ) ;
udev_event_run ( msg ) ;
return ;
}
list_add_tail ( & msg - > node , & exec_list ) ;
run_exec_q = 1 ;
}
/* runs event and removes event from run queue when finished */
2005-01-17 02:53:08 +03:00
static int running_processes ( void )
{
int f ;
2006-07-25 16:45:09 +04:00
char buf [ 32768 ] ;
2005-01-17 02:53:08 +03:00
int len ;
int running ;
const char * pos ;
f = open ( " /proc/stat " , O_RDONLY ) ;
if ( f = = - 1 )
return - 1 ;
2005-09-14 16:28:13 +04:00
len = read ( f , buf , sizeof ( buf ) - 1 ) ;
2005-01-17 02:53:08 +03:00
close ( f ) ;
if ( len < = 0 )
return - 1 ;
else
buf [ len ] = ' \0 ' ;
pos = strstr ( buf , " procs_running " ) ;
if ( pos = = NULL )
return - 1 ;
if ( sscanf ( pos , " procs_running %u " , & running ) ! = 1 )
return - 1 ;
return running ;
}
/* return the number of process es in our session, count only until limit */
static int running_processes_in_session ( pid_t session , int limit )
{
DIR * dir ;
struct dirent * dent ;
int running = 0 ;
dir = opendir ( " /proc " ) ;
if ( ! dir )
return - 1 ;
/* read process info from /proc */
for ( dent = readdir ( dir ) ; dent ! = NULL ; dent = readdir ( dir ) ) {
int f ;
char procdir [ 64 ] ;
char line [ 256 ] ;
const char * pos ;
char state ;
pid_t ppid , pgrp , sess ;
int len ;
if ( ! isdigit ( dent - > d_name [ 0 ] ) )
continue ;
snprintf ( procdir , sizeof ( procdir ) , " /proc/%s/stat " , dent - > d_name ) ;
procdir [ sizeof ( procdir ) - 1 ] = ' \0 ' ;
f = open ( procdir , O_RDONLY ) ;
if ( f = = - 1 )
continue ;
2005-09-14 16:28:13 +04:00
len = read ( f , line , sizeof ( line ) - 1 ) ;
2005-01-17 02:53:08 +03:00
close ( f ) ;
if ( len < = 0 )
continue ;
else
line [ len ] = ' \0 ' ;
/* skip ugly program name */
pos = strrchr ( line , ' ) ' ) + 2 ;
if ( pos = = NULL )
continue ;
if ( sscanf ( pos , " %c %d %d %d " , & state , & ppid , & pgrp , & sess ) ! = 4 )
continue ;
/* count only processes in our session */
if ( sess ! = session )
continue ;
/* count only running, no sleeping processes */
if ( state ! = ' R ' )
continue ;
running + + ;
if ( limit > 0 & & running > = limit )
break ;
}
closedir ( dir ) ;
return running ;
}
2005-01-05 07:35:24 +03:00
static int compare_devpath ( const char * running , const char * waiting )
{
int i ;
2005-03-07 06:29:43 +03:00
for ( i = 0 ; i < PATH_SIZE ; i + + ) {
2005-01-05 07:35:24 +03:00
/* identical device event found */
if ( running [ i ] = = ' \0 ' & & waiting [ i ] = = ' \0 ' )
return 1 ;
/* parent device event found */
if ( running [ i ] = = ' \0 ' & & waiting [ i ] = = ' / ' )
return 2 ;
/* child device event found */
if ( running [ i ] = = ' / ' & & waiting [ i ] = = ' \0 ' )
return 3 ;
/* no matching event */
if ( running [ i ] ! = waiting [ i ] )
break ;
}
return 0 ;
}
/* returns still running task for the same device, its parent or its physical device */
2006-08-05 15:22:44 +04:00
static int running_with_devpath ( struct udevd_uevent_msg * msg , int limit )
[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 11:28:57 +03:00
{
2006-08-05 15:22:44 +04:00
struct udevd_uevent_msg * loop_msg ;
2005-06-05 06:53:17 +04:00
int childs_count = 0 ;
2005-01-05 07:35:24 +03:00
2005-02-24 22:13:25 +03:00
list_for_each_entry ( loop_msg , & running_list , node ) {
2005-06-05 06:53:17 +04:00
if ( limit & & childs_count + + > limit ) {
dbg ( " %llu, maximum number (%i) of child reached " , msg - > seqnum , childs_count ) ;
return 1 ;
}
2004-11-19 05:49:13 +03:00
2005-01-05 07:35:24 +03:00
/* return running parent/child device event */
2005-06-05 06:53:17 +04:00
if ( compare_devpath ( loop_msg - > devpath , msg - > devpath ) ! = 0 ) {
dbg ( " %llu, child device event still running %llu (%s) " ,
msg - > seqnum , loop_msg - > seqnum , loop_msg - > devpath ) ;
return 2 ;
}
[PATCH] udevd: serialization of the event sequence of a chain of devices
Currently udevd delays only events for the same DEVPATH.
Example of an "add" event sequence:
/block/sda
/block/sda/sda1
With this change, we make sure, that the udev process handling
/block/sda has finished its work (waited for all attributes,
created the node) before we fork the udev event for /block/sda/sda1.
This way the event for sda1 can be sure, that the node for the
main device is already created (may be useful for disk labels).
It will not affect any parallel device handling, only the sequence
of the devices directory chain is serialized. The 10.000 disks
plugged in will still run as parallel events. :)
The main motivation to do this is the program execution of the
dev.d/ and hotplug.d/ directory. If we don't wait for the parent
event to exit, we can't be sure that the executed scripts are
run in the right order.
On Thu, Dec 09, 2004 at 09:18:28AM +0100, Kay Sievers wrote:
> On Wed, 2004-12-08 at 19:07 -0800, David Brownell wrote:
> > Could that argument apply to the underlying hardware, too?
> We now make sure that the sequence of events for a device
> is serialized for every device chain and the class/block
> devices which have a "device" link to a physical device are
> handled after the physical device is fully populated and
> notified to userspace. It will only work this way on kernels
> later than 2.6.10-rc1 cause it depends on the PHYSDEVPATH
> value in the hotplug environment.
2004-12-11 23:43:08 +03:00
2005-01-05 07:35:24 +03:00
/* return running physical device event */
[PATCH] udevd: serialization of the event sequence of a chain of devices
Currently udevd delays only events for the same DEVPATH.
Example of an "add" event sequence:
/block/sda
/block/sda/sda1
With this change, we make sure, that the udev process handling
/block/sda has finished its work (waited for all attributes,
created the node) before we fork the udev event for /block/sda/sda1.
This way the event for sda1 can be sure, that the node for the
main device is already created (may be useful for disk labels).
It will not affect any parallel device handling, only the sequence
of the devices directory chain is serialized. The 10.000 disks
plugged in will still run as parallel events. :)
The main motivation to do this is the program execution of the
dev.d/ and hotplug.d/ directory. If we don't wait for the parent
event to exit, we can't be sure that the executed scripts are
run in the right order.
On Thu, Dec 09, 2004 at 09:18:28AM +0100, Kay Sievers wrote:
> On Wed, 2004-12-08 at 19:07 -0800, David Brownell wrote:
> > Could that argument apply to the underlying hardware, too?
> We now make sure that the sequence of events for a device
> is serialized for every device chain and the class/block
> devices which have a "device" link to a physical device are
> handled after the physical device is fully populated and
> notified to userspace. It will only work this way on kernels
> later than 2.6.10-rc1 cause it depends on the PHYSDEVPATH
> value in the hotplug environment.
2004-12-11 23:43:08 +03:00
if ( msg - > physdevpath & & msg - > action & & strcmp ( msg - > action , " add " ) = = 0 )
2005-06-05 06:53:17 +04:00
if ( compare_devpath ( loop_msg - > devpath , msg - > physdevpath ) ! = 0 ) {
dbg ( " %llu, physical device event still running %llu (%s) " ,
msg - > seqnum , loop_msg - > seqnum , loop_msg - > devpath ) ;
return 3 ;
}
2004-11-19 05:49:13 +03:00
}
2005-06-05 06:53:17 +04:00
return 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 11:28:57 +03:00
}
[PATCH] udevd: serialization of the event sequence of a chain of devices
Currently udevd delays only events for the same DEVPATH.
Example of an "add" event sequence:
/block/sda
/block/sda/sda1
With this change, we make sure, that the udev process handling
/block/sda has finished its work (waited for all attributes,
created the node) before we fork the udev event for /block/sda/sda1.
This way the event for sda1 can be sure, that the node for the
main device is already created (may be useful for disk labels).
It will not affect any parallel device handling, only the sequence
of the devices directory chain is serialized. The 10.000 disks
plugged in will still run as parallel events. :)
The main motivation to do this is the program execution of the
dev.d/ and hotplug.d/ directory. If we don't wait for the parent
event to exit, we can't be sure that the executed scripts are
run in the right order.
On Thu, Dec 09, 2004 at 09:18:28AM +0100, Kay Sievers wrote:
> On Wed, 2004-12-08 at 19:07 -0800, David Brownell wrote:
> > Could that argument apply to the underlying hardware, too?
> We now make sure that the sequence of events for a device
> is serialized for every device chain and the class/block
> devices which have a "device" link to a physical device are
> handled after the physical device is fully populated and
> notified to userspace. It will only work this way on kernels
> later than 2.6.10-rc1 cause it depends on the PHYSDEVPATH
> value in the hotplug environment.
2004-12-11 23:43:08 +03:00
/* exec queue management routine executes the events and serializes events in the same sequence */
2005-11-07 16:10:09 +03:00
static void msg_queue_manager ( 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 11:28:57 +03:00
{
2006-08-05 15:22:44 +04:00
struct udevd_uevent_msg * loop_msg ;
struct udevd_uevent_msg * tmp_msg ;
2005-01-17 02:53:08 +03:00
int running ;
2005-06-16 03:58:47 +04:00
if ( list_empty ( & exec_list ) )
return ;
2005-01-17 02:53:08 +03:00
running = running_processes ( ) ;
dbg ( " %d processes runnning on system " , running ) ;
if ( running < 0 )
2005-06-05 06:53:17 +04:00
running = max_childs_running ;
[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 20:12:36 +03:00
2005-02-24 22:13:25 +03:00
list_for_each_entry_safe ( loop_msg , tmp_msg , & exec_list , node ) {
2005-01-17 02:53:08 +03:00
/* check running processes in our session and possibly throttle */
2005-06-05 06:53:17 +04:00
if ( running > = max_childs_running ) {
running = running_processes_in_session ( sid , max_childs_running + 10 ) ;
dbg ( " at least %d processes running in session " , running ) ;
if ( running > = max_childs_running ) {
2005-11-07 16:10:09 +03:00
dbg ( " delay seq %llu, too many processes already running " , loop_msg - > seqnum ) ;
2005-01-17 02:53:08 +03:00
return ;
}
}
2005-11-07 16:10:09 +03:00
/* don't run two processes for the same devpath and wait for the parent*/
if ( running_with_devpath ( loop_msg , max_childs ) ) {
2005-06-05 06:53:17 +04:00
dbg ( " delay seq %llu (%s) " , loop_msg - > seqnum , loop_msg - > devpath ) ;
2005-11-07 16:10:09 +03:00
continue ;
}
/* move event to run list */
list_move_tail ( & loop_msg - > node , & running_list ) ;
udev_event_run ( loop_msg ) ;
running + + ;
dbg ( " moved seq %llu to running list " , loop_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 20:12:36 +03:00
}
}
2006-08-05 15:22:44 +04:00
static struct udevd_uevent_msg * get_msg_from_envbuf ( const char * buf , int buf_size )
2005-06-05 06:38:10 +04:00
{
int bufpos ;
int i ;
2006-08-05 15:22:44 +04:00
struct udevd_uevent_msg * msg ;
2005-07-06 04:02:05 +04:00
int major = 0 ;
int minor = 0 ;
2005-06-05 06:38:10 +04:00
2006-08-05 15:22:44 +04:00
msg = malloc ( sizeof ( struct udevd_uevent_msg ) + buf_size ) ;
2005-06-05 06:38:10 +04:00
if ( msg = = NULL )
return NULL ;
2006-08-05 15:22:44 +04:00
memset ( msg , 0x00 , sizeof ( struct udevd_uevent_msg ) + buf_size ) ;
2005-06-05 06:38:10 +04:00
/* copy environment buffer and reconstruct envp */
memcpy ( msg - > envbuf , buf , buf_size ) ;
bufpos = 0 ;
2005-06-05 06:41:09 +04:00
for ( i = 0 ; ( bufpos < buf_size ) & & ( i < UEVENT_NUM_ENVP - 2 ) ; i + + ) {
2005-06-05 06:38:10 +04:00
int keylen ;
char * key ;
key = & msg - > envbuf [ bufpos ] ;
keylen = strlen ( key ) ;
msg - > envp [ i ] = key ;
bufpos + = keylen + 1 ;
dbg ( " add '%s' to msg.envp[%i] " , msg - > envp [ i ] , i ) ;
/* remember some keys for further processing */
if ( strncmp ( key , " ACTION= " , 7 ) = = 0 )
msg - > action = & key [ 7 ] ;
2005-07-06 04:02:05 +04:00
else if ( strncmp ( key , " DEVPATH= " , 8 ) = = 0 )
2005-06-05 06:38:10 +04:00
msg - > devpath = & key [ 8 ] ;
2005-07-06 04:02:05 +04:00
else if ( strncmp ( key , " SUBSYSTEM= " , 10 ) = = 0 )
2005-06-05 06:38:10 +04:00
msg - > subsystem = & key [ 10 ] ;
2005-07-06 04:02:05 +04:00
else if ( strncmp ( key , " SEQNUM= " , 7 ) = = 0 )
2005-06-05 06:38:10 +04:00
msg - > seqnum = strtoull ( & key [ 7 ] , NULL , 10 ) ;
2005-07-06 04:02:05 +04:00
else if ( strncmp ( key , " PHYSDEVPATH= " , 12 ) = = 0 )
2005-06-05 06:38:10 +04:00
msg - > physdevpath = & key [ 12 ] ;
2005-07-06 04:02:05 +04:00
else if ( strncmp ( key , " MAJOR= " , 6 ) = = 0 )
major = strtoull ( & key [ 6 ] , NULL , 10 ) ;
else if ( strncmp ( key , " MINOR= " , 6 ) = = 0 )
minor = strtoull ( & key [ 6 ] , NULL , 10 ) ;
else if ( strncmp ( key , " TIMEOUT= " , 8 ) = = 0 )
2005-06-05 06:38:10 +04:00
msg - > timeout = strtoull ( & key [ 8 ] , NULL , 10 ) ;
}
2005-07-06 04:02:05 +04:00
msg - > devt = makedev ( major , minor ) ;
2005-06-05 06:38:10 +04:00
msg - > envp [ i + + ] = " UDEVD_EVENT=1 " ;
msg - > envp [ i ] = NULL ;
2006-01-20 04:54:31 +03:00
if ( msg - > devpath = = NULL | | msg - > action = = NULL ) {
info ( " DEVPATH or ACTION missing, ignore message " ) ;
2005-11-16 02:13:28 +03:00
free ( msg ) ;
return NULL ;
}
2005-06-05 06:38:10 +04:00
return msg ;
}
2005-06-05 06:41:09 +04:00
/* receive the udevd message from userspace */
2006-08-05 15:22:44 +04:00
static void get_ctrl_msg ( 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 11:28:57 +03:00
{
2006-08-05 15:22:44 +04:00
struct udevd_ctrl_msg ctrl_msg ;
2004-11-06 16:30:15 +03:00
ssize_t size ;
2004-02-12 09:32:11 +03:00
struct msghdr smsg ;
struct cmsghdr * cmsg ;
struct iovec iov ;
struct ucred * cred ;
char cred_msg [ CMSG_SPACE ( sizeof ( struct ucred ) ) ] ;
2005-06-16 03:58:47 +04:00
int * intval ;
2004-01-27 05:19:33 +03:00
2006-08-05 15:22:44 +04:00
memset ( & ctrl_msg , 0x00 , sizeof ( struct udevd_ctrl_msg ) ) ;
2006-05-27 14:20:51 +04:00
iov . iov_base = & ctrl_msg ;
2006-08-05 15:22:44 +04:00
iov . iov_len = sizeof ( struct udevd_ctrl_msg ) ;
2004-02-12 09:32:11 +03:00
memset ( & smsg , 0x00 , sizeof ( struct msghdr ) ) ;
smsg . msg_iov = & iov ;
smsg . msg_iovlen = 1 ;
smsg . msg_control = cred_msg ;
smsg . msg_controllen = sizeof ( cred_msg ) ;
2005-06-05 06:41:09 +04:00
size = recvmsg ( udevd_sock , & smsg , 0 ) ;
2004-11-06 16:30:15 +03:00
if ( size < 0 ) {
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
if ( errno ! = EINTR )
2005-12-04 03:48:53 +03:00
err ( " unable to receive user udevd message: %s " , strerror ( errno ) ) ;
2006-07-25 16:45:09 +04:00
return ;
[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 20:12:36 +03:00
}
2004-02-12 09:32:11 +03:00
cmsg = CMSG_FIRSTHDR ( & smsg ) ;
cred = ( struct ucred * ) CMSG_DATA ( cmsg ) ;
2004-02-12 12:23:59 +03:00
if ( cmsg = = NULL | | cmsg - > cmsg_type ! = SCM_CREDENTIALS ) {
2005-08-29 01:19:45 +04:00
err ( " no sender credentials received, message ignored " ) ;
2006-07-25 16:45:09 +04:00
return ;
2004-02-12 12:23:59 +03:00
}
2004-02-12 09:32:11 +03:00
if ( cred - > uid ! = 0 ) {
2005-08-29 01:19:45 +04:00
err ( " sender uid=%i, message ignored " , cred - > uid ) ;
2006-07-25 16:45:09 +04:00
return ;
2004-11-06 16:30:15 +03:00
}
2006-08-05 15:22:44 +04:00
if ( strncmp ( ctrl_msg . magic , UDEVD_CTRL_MAGIC , sizeof ( UDEVD_CTRL_MAGIC ) ) ! = 0 ) {
2006-05-27 14:20:51 +04:00
err ( " message magic '%s' doesn't match, ignore it " , ctrl_msg . magic ) ;
2006-07-25 16:45:09 +04:00
return ;
2004-02-12 09:32:11 +03:00
}
2006-05-27 14:20:51 +04:00
switch ( ctrl_msg . type ) {
2006-08-05 15:22:44 +04:00
case UDEVD_CTRL_STOP_EXEC_QUEUE :
2005-06-16 03:58:47 +04:00
info ( " udevd message (STOP_EXEC_QUEUE) received " ) ;
2005-06-05 06:41:09 +04:00
stop_exec_q = 1 ;
break ;
2006-08-05 15:22:44 +04:00
case UDEVD_CTRL_START_EXEC_QUEUE :
2005-06-16 03:58:47 +04:00
info ( " udevd message (START_EXEC_QUEUE) received " ) ;
2005-06-05 06:41:09 +04:00
stop_exec_q = 0 ;
2005-11-07 16:10:09 +03:00
msg_queue_manager ( ) ;
2005-06-05 06:41:09 +04:00
break ;
2006-08-05 15:22:44 +04:00
case UDEVD_CTRL_SET_LOG_LEVEL :
intval = ( int * ) ctrl_msg . buf ;
2005-06-16 03:58:47 +04:00
info ( " udevd message (SET_LOG_PRIORITY) received, udev_log_priority=%i " , * intval ) ;
udev_log_priority = * intval ;
2005-10-27 22:32:07 +04:00
sprintf ( udev_log , " UDEV_LOG=%i " , udev_log_priority ) ;
putenv ( udev_log ) ;
2005-06-16 03:58:47 +04:00
break ;
2006-08-05 15:22:44 +04:00
case UDEVD_CTRL_SET_MAX_CHILDS :
intval = ( int * ) ctrl_msg . buf ;
2005-06-16 03:58:47 +04:00
info ( " udevd message (UDEVD_SET_MAX_CHILDS) received, max_childs=%i " , * intval ) ;
max_childs = * intval ;
break ;
2006-08-05 15:22:44 +04:00
case UDEVD_CTRL_RELOAD_RULES :
2005-10-27 23:04:38 +04:00
info ( " udevd message (RELOAD_RULES) received " ) ;
reload_config = 1 ;
break ;
2005-06-05 06:41:09 +04:00
default :
dbg ( " unknown message type " ) ;
}
2005-06-05 06:38:10 +04:00
}
2004-11-06 16:30:15 +03:00
2005-06-05 06:38:10 +04:00
/* receive the kernel user event message and do some sanity checks */
2006-08-05 15:22:44 +04:00
static struct udevd_uevent_msg * get_netlink_msg ( void )
2005-06-05 06:38:10 +04:00
{
2006-08-05 15:22:44 +04:00
struct udevd_uevent_msg * msg ;
2005-06-05 06:38:10 +04:00
int bufpos ;
ssize_t size ;
2006-01-24 14:12:07 +03:00
static char buffer [ UEVENT_BUFFER_SIZE + 512 ] ;
2005-06-05 06:38:10 +04:00
char * pos ;
2004-11-06 16:30:15 +03:00
2005-06-16 03:58:47 +04:00
size = recv ( uevent_netlink_sock , & buffer , sizeof ( buffer ) , 0 ) ;
2005-06-05 06:38:10 +04:00
if ( size < 0 ) {
if ( errno ! = EINTR )
2005-12-04 03:48:53 +03:00
err ( " unable to receive kernel netlink message: %s " , strerror ( errno ) ) ;
2005-06-05 06:38:10 +04:00
return NULL ;
}
2004-11-06 16:30:15 +03:00
2005-06-05 06:38:10 +04:00
if ( ( size_t ) size > sizeof ( buffer ) - 1 )
size = sizeof ( buffer ) - 1 ;
buffer [ size ] = ' \0 ' ;
2005-07-06 04:02:05 +04:00
dbg ( " uevent_size=%zi " , size ) ;
2004-11-06 16:30:15 +03:00
2005-06-05 06:38:10 +04:00
/* start of event payload */
bufpos = strlen ( buffer ) + 1 ;
msg = get_msg_from_envbuf ( & buffer [ bufpos ] , size - bufpos ) ;
if ( msg = = NULL )
return NULL ;
2004-11-06 16:30:15 +03:00
2005-06-05 06:38:10 +04:00
/* validate message */
pos = strchr ( buffer , ' @ ' ) ;
if ( pos = = NULL ) {
2005-08-29 01:19:45 +04:00
err ( " invalid uevent '%s' " , buffer ) ;
2005-06-05 06:38:10 +04:00
free ( msg ) ;
return NULL ;
}
pos [ 0 ] = ' \0 ' ;
[PATCH] udevd: serialization of the event sequence of a chain of devices
Currently udevd delays only events for the same DEVPATH.
Example of an "add" event sequence:
/block/sda
/block/sda/sda1
With this change, we make sure, that the udev process handling
/block/sda has finished its work (waited for all attributes,
created the node) before we fork the udev event for /block/sda/sda1.
This way the event for sda1 can be sure, that the node for the
main device is already created (may be useful for disk labels).
It will not affect any parallel device handling, only the sequence
of the devices directory chain is serialized. The 10.000 disks
plugged in will still run as parallel events. :)
The main motivation to do this is the program execution of the
dev.d/ and hotplug.d/ directory. If we don't wait for the parent
event to exit, we can't be sure that the executed scripts are
run in the right order.
On Thu, Dec 09, 2004 at 09:18:28AM +0100, Kay Sievers wrote:
> On Wed, 2004-12-08 at 19:07 -0800, David Brownell wrote:
> > Could that argument apply to the underlying hardware, too?
> We now make sure that the sequence of events for a device
> is serialized for every device chain and the class/block
> devices which have a "device" link to a physical device are
> handled after the physical device is fully populated and
> notified to userspace. It will only work this way on kernels
> later than 2.6.10-rc1 cause it depends on the PHYSDEVPATH
> value in the hotplug environment.
2004-12-11 23:43:08 +03:00
2005-06-05 06:38:10 +04:00
if ( msg - > action = = NULL ) {
2005-10-12 13:55:49 +04:00
info ( " no ACTION in payload found, skip event '%s' " , buffer ) ;
2005-06-05 06:38:10 +04:00
free ( msg ) ;
return NULL ;
}
2005-03-17 13:51:37 +03:00
2005-06-05 06:38:10 +04:00
if ( strcmp ( msg - > action , buffer ) ! = 0 ) {
2005-08-29 01:19:45 +04:00
err ( " ACTION in payload does not match uevent, skip event '%s' " , buffer ) ;
2005-06-05 06:38:10 +04:00
free ( msg ) ;
return NULL ;
[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 20:12:36 +03:00
}
2004-01-27 05:19:33 +03:00
2005-01-05 07:37:50 +03:00
return msg ;
2004-01-27 05:19:33 +03:00
}
2004-01-24 09:26:19 +03:00
2004-10-14 09:38:15 +04:00
static void asmlinkage 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 11:28:57 +03: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 20:12:36 +03:00
switch ( signum ) {
case SIGINT :
case SIGTERM :
2005-08-08 07:07:36 +04:00
udev_exit = 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 20:12:36 +03:00
break ;
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
case SIGCHLD :
2004-04-01 11:03:07 +04:00
/* set flag, then write to pipe if needed */
2004-10-19 15:37:30 +04:00
sigchilds_waiting = 1 ;
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
break ;
2005-10-27 23:04:38 +04:00
case SIGHUP :
reload_config = 1 ;
break ;
2004-04-01 11:03:07 +04:00
}
2004-11-05 15:16:32 +03:00
2005-08-29 01:13:14 +04:00
/* write to pipe, which will wakeup select() in our mainloop */
write ( signal_pipe [ WRITE_END ] , " " , 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 08:25:17 +03: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 11:28:57 +03:00
2005-11-16 04:06:46 +03:00
static void udev_done ( int pid , int exitstatus )
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
{
/* find msg associated with pid and delete it */
2006-08-05 15:22:44 +04:00
struct udevd_uevent_msg * msg ;
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
2005-02-24 22:13:25 +03:00
list_for_each_entry ( msg , & running_list , node ) {
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
if ( msg - > pid = = pid ) {
2005-11-16 04:06:46 +03:00
info ( " seq %llu, pid [%d] exit with %i, %ld seconds old " , msg - > seqnum , msg - > pid ,
exitstatus , time ( NULL ) - msg - > queue_time ) ;
msg - > exitstatus = exitstatus ;
2005-07-06 04:02:05 +04:00
msg_queue_delete ( msg ) ;
2004-09-05 20:05:29 +04:00
2005-11-07 16:10:09 +03:00
/* there may be events waiting with the same devpath */
2004-04-01 11:03:07 +04:00
run_exec_q = 1 ;
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
return ;
}
}
}
2004-10-19 15:37:30 +04:00
static void reap_sigchilds ( void )
2004-04-01 11:03:07 +04:00
{
2005-08-15 13:57:04 +04:00
pid_t pid ;
2005-11-16 04:06:46 +03:00
int status ;
2005-01-16 06:39:02 +03:00
2005-08-15 13:57:04 +04:00
while ( 1 ) {
2005-11-16 04:06:46 +03:00
pid = waitpid ( - 1 , & status , WNOHANG ) ;
2005-08-15 13:57:04 +04:00
if ( pid < = 0 )
2004-04-01 11:03:07 +04:00
break ;
2005-11-16 04:06:46 +03:00
if ( WIFEXITED ( status ) )
status = WEXITSTATUS ( status ) ;
2005-11-17 18:34:37 +03:00
else if ( WIFSIGNALED ( status ) )
status = WTERMSIG ( status ) + 128 ;
2005-11-16 04:06:46 +03:00
else
status = 0 ;
udev_done ( pid , status ) ;
2004-04-01 11:03:07 +04:00
}
}
2005-06-05 06:41:09 +04:00
static int init_udevd_socket ( void )
[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 08:25:17 +03: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 20:12:36 +03:00
struct sockaddr_un saddr ;
2005-10-11 23:06:50 +04:00
const int buffersize = 16 * 1024 * 1024 ;
2004-02-06 11:11:24 +03:00
socklen_t addrlen ;
2004-10-19 15:37:30 +04:00
const int feature_on = 1 ;
2005-01-16 06:08:54 +03:00
int retval ;
memset ( & saddr , 0x00 , sizeof ( saddr ) ) ;
saddr . sun_family = AF_LOCAL ;
/* use abstract namespace for socket path */
2006-08-05 15:22:44 +04:00
strcpy ( & saddr . sun_path [ 1 ] , UDEVD_CTRL_SOCK_PATH ) ;
2005-01-16 06:08:54 +03:00
addrlen = offsetof ( struct sockaddr_un , sun_path ) + strlen ( saddr . sun_path + 1 ) + 1 ;
2005-06-05 06:41:09 +04:00
udevd_sock = socket ( AF_LOCAL , SOCK_DGRAM , 0 ) ;
if ( udevd_sock = = - 1 ) {
2005-11-07 20:44:18 +03:00
err ( " error getting socket: %s " , strerror ( errno ) ) ;
2005-01-16 06:08:54 +03:00
return - 1 ;
}
2005-07-12 13:44:51 +04:00
/* set receive buffersize */
2005-10-11 23:06:50 +04:00
setsockopt ( udevd_sock , SOL_SOCKET , SO_RCVBUFFORCE , & buffersize , sizeof ( buffersize ) ) ;
2005-07-12 13:44:51 +04:00
2005-01-16 06:08:54 +03:00
/* the bind takes care of ensuring only one copy running */
2005-06-05 06:41:09 +04:00
retval = bind ( udevd_sock , ( struct sockaddr * ) & saddr , addrlen ) ;
2005-01-16 06:08:54 +03:00
if ( retval < 0 ) {
2005-11-07 20:44:18 +03:00
err ( " bind failed: %s " , strerror ( errno ) ) ;
2005-01-16 06:08:54 +03:00
return - 1 ;
}
/* enable receiving of the sender credentials */
2005-06-05 06:41:09 +04:00
setsockopt ( udevd_sock , SOL_SOCKET , SO_PASSCRED , & feature_on , sizeof ( feature_on ) ) ;
2005-01-16 06:08:54 +03:00
return 0 ;
}
2005-06-16 03:58:47 +04:00
static int init_uevent_netlink_sock ( void )
2005-06-05 06:38:10 +04:00
{
struct sockaddr_nl snl ;
2005-10-11 23:06:50 +04:00
const int buffersize = 16 * 1024 * 1024 ;
2005-06-05 06:38:10 +04:00
int retval ;
memset ( & snl , 0x00 , sizeof ( struct sockaddr_nl ) ) ;
snl . nl_family = AF_NETLINK ;
snl . nl_pid = getpid ( ) ;
2006-07-21 23:41:11 +04:00
snl . nl_groups = 1 ;
2005-06-05 06:38:10 +04:00
2005-06-16 03:58:47 +04:00
uevent_netlink_sock = socket ( PF_NETLINK , SOCK_DGRAM , NETLINK_KOBJECT_UEVENT ) ;
if ( uevent_netlink_sock = = - 1 ) {
2005-11-07 20:44:18 +03:00
err ( " error getting socket: %s " , strerror ( errno ) ) ;
2005-06-05 06:38:10 +04:00
return - 1 ;
}
2005-07-12 13:44:51 +04:00
/* set receive buffersize */
2005-10-11 23:06:50 +04:00
setsockopt ( uevent_netlink_sock , SOL_SOCKET , SO_RCVBUFFORCE , & buffersize , sizeof ( buffersize ) ) ;
2005-07-12 13:44:51 +04:00
2005-11-04 07:25:15 +03:00
retval = bind ( uevent_netlink_sock , ( struct sockaddr * ) & snl , sizeof ( struct sockaddr_nl ) ) ;
2005-06-05 06:38:10 +04:00
if ( retval < 0 ) {
2005-11-07 20:44:18 +03:00
err ( " bind failed: %s " , strerror ( errno ) ) ;
2005-06-16 03:58:47 +04:00
close ( uevent_netlink_sock ) ;
uevent_netlink_sock = - 1 ;
2005-06-05 06:38:10 +04:00
return - 1 ;
}
return 0 ;
}
2006-04-25 20:50:56 +04:00
static void export_initial_seqnum ( void )
{
char filename [ PATH_SIZE ] ;
int fd ;
char seqnum [ 32 ] ;
ssize_t len = 0 ;
strlcpy ( filename , sysfs_path , sizeof ( filename ) ) ;
strlcat ( filename , " /kernel/uevent_seqnum " , sizeof ( filename ) ) ;
fd = open ( filename , O_RDONLY ) ;
if ( fd > = 0 ) {
len = read ( fd , seqnum , sizeof ( seqnum ) - 1 ) ;
close ( fd ) ;
}
if ( len < = 0 ) {
strcpy ( seqnum , " 0 \n " ) ;
len = 3 ;
}
strlcpy ( filename , udev_root , sizeof ( filename ) ) ;
strlcat ( filename , " / " EVENT_SEQNUM , sizeof ( filename ) ) ;
2006-04-28 02:34:05 +04:00
create_path ( filename ) ;
2006-04-25 20:50:56 +04:00
fd = open ( filename , O_WRONLY | O_TRUNC | O_CREAT , 0644 ) ;
if ( fd > = 0 ) {
write ( fd , seqnum , len ) ;
close ( fd ) ;
}
}
2005-01-16 06:08:54 +03:00
int main ( int argc , char * argv [ ] , char * envp [ ] )
{
int retval ;
2005-11-05 21:41:00 +03:00
int fd ;
2004-02-12 09:29:15 +03:00
struct sigaction act ;
2004-04-01 11:03:07 +04:00
fd_set readfds ;
2005-06-05 06:53:17 +04:00
const char * value ;
2005-06-08 13:57:53 +04:00
int daemonize = 0 ;
int i ;
2005-11-04 07:25:15 +03:00
int rc = 0 ;
2005-11-07 04:22:44 +03:00
int maxfd ;
[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 20:12:36 +03:00
2005-11-04 07:25:15 +03:00
/* redirect std fd's, if the kernel forks us, we don't have them at all */
2005-11-05 21:41:00 +03:00
fd = open ( " /dev/null " , O_RDWR ) ;
if ( fd > = 0 ) {
if ( fd ! = STDIN_FILENO )
dup2 ( fd , STDIN_FILENO ) ;
if ( fd ! = STDOUT_FILENO )
dup2 ( fd , STDOUT_FILENO ) ;
if ( fd ! = STDERR_FILENO )
dup2 ( fd , STDERR_FILENO ) ;
if ( fd > STDERR_FILENO )
close ( fd ) ;
2005-08-18 15:07:15 +04:00
}
2004-10-19 05:15:10 +04:00
logging_init ( " udevd " ) ;
2005-11-05 21:41:00 +03:00
if ( fd < 0 )
2005-11-07 20:44:18 +03:00
err ( " fatal, could not open /dev/null: %s " , strerror ( errno ) ) ;
2005-08-18 15:07:15 +04:00
2006-01-09 23:18:00 +03:00
udev_config_init ( ) ;
2004-02-17 09:31:15 +03:00
dbg ( " version %s " , UDEV_VERSION ) ;
2004-02-02 19:19:41 +03:00
2004-02-12 12:23:59 +03:00
if ( getuid ( ) ! = 0 ) {
2005-03-27 03:11:03 +04:00
err ( " need to be root, exit " ) ;
2004-11-23 05:28:41 +03:00
goto exit ;
2004-02-12 12:23:59 +03:00
}
2004-10-19 15:37:30 +04:00
2005-11-04 07:25:15 +03:00
/* parse commandline options */
2005-06-08 13:57:53 +04:00
for ( i = 1 ; i < argc ; i + + ) {
char * arg = argv [ i ] ;
if ( strcmp ( arg , " --daemon " ) = = 0 | | strcmp ( arg , " -d " ) = = 0 ) {
info ( " will daemonize " ) ;
daemonize = 1 ;
}
if ( strcmp ( arg , " --stop-exec-queue " ) = = 0 ) {
2005-06-16 03:58:47 +04:00
info ( " will not execute events until START_EXEC_QUEUE is received " ) ;
2005-06-08 13:57:53 +04:00
stop_exec_q = 1 ;
}
}
2005-08-15 13:57:04 +04:00
2005-11-04 07:25:15 +03:00
/* init sockets to receive events */
if ( init_udevd_socket ( ) < 0 ) {
if ( errno = = EADDRINUSE ) {
2005-11-07 20:52:03 +03:00
err ( " another udevd running, exit " ) ;
2005-11-04 07:25:15 +03:00
rc = 1 ;
} else {
2005-11-07 20:52:03 +03:00
err ( " error initializing udevd socket: %s " , strerror ( errno ) ) ;
2005-11-04 07:25:15 +03:00
rc = 2 ;
}
goto exit ;
}
if ( init_uevent_netlink_sock ( ) < 0 ) {
err ( " uevent socket not available " ) ;
rc = 3 ;
goto exit ;
}
/* parse the rules and keep it in memory */
2006-01-09 23:18:00 +03:00
sysfs_init ( ) ;
2005-11-05 22:00:31 +03:00
udev_rules_init ( & rules , 1 ) ;
2005-11-04 07:25:15 +03:00
2006-04-25 20:50:56 +04:00
export_initial_seqnum ( ) ;
2005-06-08 13:57:53 +04:00
if ( daemonize ) {
2005-01-16 06:06:22 +03:00
pid_t pid ;
pid = fork ( ) ;
switch ( pid ) {
case 0 :
2005-11-04 07:25:15 +03:00
dbg ( " daemonized fork running " ) ;
2005-01-16 06:06:22 +03:00
break ;
case - 1 :
2005-11-07 20:44:18 +03:00
err ( " fork of daemon failed: %s " , strerror ( errno ) ) ;
2005-11-04 07:25:15 +03:00
rc = 4 ;
2005-01-16 06:06:22 +03:00
goto exit ;
default :
2005-11-04 07:25:15 +03:00
dbg ( " child [%u] running, parent exits " , pid ) ;
goto exit ;
2005-01-16 06:06:22 +03:00
}
}
2005-11-05 21:41:00 +03:00
/* set scheduling priority for the daemon */
2005-01-17 02:53:08 +03:00
setpriority ( PRIO_PROCESS , 0 , UDEVD_PRIORITY ) ;
2005-11-05 21:41:00 +03:00
chdir ( " / " ) ;
2005-11-06 00:02:21 +03:00
umask ( 022 ) ;
2005-11-05 21:41:00 +03:00
/* become session leader */
sid = setsid ( ) ;
dbg ( " our session is %d " , sid ) ;
/* OOM_DISABLE == -17 */
fd = open ( " /proc/self/oom_adj " , O_RDWR ) ;
if ( fd < 0 )
2005-11-07 20:44:18 +03:00
err ( " error disabling OOM: %s " , strerror ( errno ) ) ;
2005-11-05 21:41:00 +03:00
else {
write ( fd , " -17 " , 3 ) ;
close ( fd ) ;
}
2004-04-01 11:03:07 +04:00
/* setup signal handler pipe */
2005-08-28 22:25:37 +04:00
retval = pipe ( signal_pipe ) ;
2004-04-01 11:03:46 +04:00
if ( retval < 0 ) {
2005-03-27 03:11:03 +04:00
err ( " error getting pipes: %s " , strerror ( errno ) ) ;
2004-11-23 05:28:41 +03:00
goto exit ;
2004-04-01 11:03:46 +04:00
}
2006-03-16 12:47:31 +03:00
retval = fcntl ( signal_pipe [ READ_END ] , F_GETFL , 0 ) ;
if ( retval < 0 ) {
err ( " error fcntl on read pipe: %s " , strerror ( errno ) ) ;
goto exit ;
}
retval = fcntl ( signal_pipe [ READ_END ] , F_SETFL , retval | O_NONBLOCK ) ;
2004-10-06 11:48:10 +04:00
if ( retval < 0 ) {
2005-03-27 03:11:03 +04:00
err ( " error fcntl on read pipe: %s " , strerror ( errno ) ) ;
2004-11-23 05:28:41 +03:00
goto exit ;
2004-10-06 11:48:10 +04:00
}
2006-03-16 12:47:31 +03:00
retval = fcntl ( signal_pipe [ WRITE_END ] , F_GETFL , 0 ) ;
if ( retval < 0 ) {
err ( " error fcntl on write pipe: %s " , strerror ( errno ) ) ;
goto exit ;
}
retval = fcntl ( signal_pipe [ WRITE_END ] , F_SETFL , retval | O_NONBLOCK ) ;
2004-04-01 11:03:46 +04:00
if ( retval < 0 ) {
2005-03-27 03:11:03 +04:00
err ( " error fcntl on write pipe: %s " , strerror ( errno ) ) ;
2004-11-23 05:28:41 +03:00
goto exit ;
2004-04-01 11:03:46 +04:00
}
2004-04-01 11:03:07 +04:00
/* set signal handlers */
2005-02-06 02:09:34 +03:00
memset ( & act , 0x00 , sizeof ( struct sigaction ) ) ;
2005-03-27 03:11:03 +04:00
act . sa_handler = ( void ( * ) ( int ) ) sig_handler ;
2004-04-01 11:03:07 +04:00
sigemptyset ( & act . sa_mask ) ;
2004-02-12 09:29:15 +03:00
act . sa_flags = SA_RESTART ;
sigaction ( SIGINT , & act , NULL ) ;
sigaction ( SIGTERM , & act , NULL ) ;
sigaction ( SIGCHLD , & act , NULL ) ;
2005-08-08 07:07:36 +04:00
sigaction ( SIGHUP , & act , 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 11:28:57 +03:00
2005-10-27 23:04:38 +04:00
/* watch rules directory */
inotify_fd = inotify_init ( ) ;
2006-04-06 21:52:41 +04:00
if ( inotify_fd > = 0 )
2005-10-27 23:04:38 +04:00
inotify_add_watch ( inotify_fd , udev_rules_filename , IN_CREATE | IN_DELETE | IN_MOVE | IN_CLOSE_WRITE ) ;
2006-04-06 21:52:41 +04:00
else if ( errno = = ENOSYS )
err ( " the kernel does not support inotify, udevd can't monitor configuration file changes " ) ;
else
err ( " inotify_init failed: %s " , strerror ( errno ) ) ;
2004-02-12 09:32:11 +03:00
2005-06-05 06:53:17 +04:00
/* maximum limit of forked childs */
value = getenv ( " UDEVD_MAX_CHILDS " ) ;
if ( value )
max_childs = strtoul ( value , NULL , 10 ) ;
else
max_childs = UDEVD_MAX_CHILDS ;
info ( " initialize max_childs to %u " , max_childs ) ;
/* start to throttle forking if maximum number of _running_ childs is reached */
value = getenv ( " UDEVD_MAX_CHILDS_RUNNING " ) ;
if ( value )
max_childs_running = strtoull ( value , NULL , 10 ) ;
else
max_childs_running = UDEVD_MAX_CHILDS_RUNNING ;
info ( " initialize max_childs_running to %u " , max_childs_running ) ;
2005-01-05 07:33:26 +03:00
2005-10-27 23:04:38 +04:00
/* clear environment for forked event processes */
clearenv ( ) ;
2005-08-15 13:57:04 +04:00
/* export log_priority , as called programs may want to follow that setting */
2005-10-27 22:32:07 +04:00
sprintf ( udev_log , " UDEV_LOG=%i " , udev_log_priority ) ;
putenv ( udev_log ) ;
2005-08-15 13:57:04 +04:00
2005-11-07 04:22:44 +03:00
maxfd = udevd_sock ;
maxfd = UDEV_MAX ( maxfd , uevent_netlink_sock ) ;
maxfd = UDEV_MAX ( maxfd , signal_pipe [ READ_END ] ) ;
maxfd = UDEV_MAX ( maxfd , inotify_fd ) ;
2005-08-08 07:07:36 +04:00
while ( ! udev_exit ) {
2006-08-05 15:22:44 +04:00
struct udevd_uevent_msg * msg ;
2005-08-15 13:57:04 +04:00
int fdcount ;
2005-01-05 07:37:50 +03:00
2005-08-15 13:57:04 +04:00
FD_ZERO ( & readfds ) ;
2005-08-28 22:25:37 +04:00
FD_SET ( signal_pipe [ READ_END ] , & readfds ) ;
2005-08-15 13:57:04 +04:00
FD_SET ( udevd_sock , & readfds ) ;
2005-11-04 07:25:15 +03:00
FD_SET ( uevent_netlink_sock , & readfds ) ;
2006-04-25 20:50:56 +04:00
if ( inotify_fd > = 0 )
2005-10-27 23:04:38 +04:00
FD_SET ( inotify_fd , & readfds ) ;
2004-04-01 11:03:46 +04:00
2005-11-07 04:22:44 +03:00
fdcount = select ( maxfd + 1 , & readfds , NULL , NULL , NULL ) ;
2005-08-15 13:57:04 +04:00
if ( fdcount < 0 ) {
2004-04-01 11:03:46 +04:00
if ( errno ! = EINTR )
2005-11-07 20:52:03 +03:00
err ( " error in select: %s " , strerror ( errno ) ) ;
2004-04-01 11:03:07 +04:00
continue ;
[PATCH] convert udevsend/udevd to DGRAM and single-threaded
On Fri, Feb 06, 2004 at 01:08:24AM -0500, Chris Friesen wrote:
>
> Kay, you said "unless we can get rid of _all_ the threads or at least
> getting faster, I don't want to change it."
>
> Well how about we get rid of all the threads, *and* we get faster?
Yes, we are twice as fast now on my box :)
> This patch applies to current bk trees, and does the following:
>
> 1) Switch to DGRAM sockets rather than STREAM. This simplifies things
> as mentioned in the previous message.
>
> 2) Invalid sequence numbers are mapped to -1 rather than zero, since
> zero is a valid sequence number (I think). Also, this allows for real
> speed tests using scripts starting at a zero sequence number, since that
> is what the initial expected sequence number is.
>
> 3) Get rid of all threading. This is the biggie. Some highlights:
> a) timeout using setitimer() and SIGALRM
> b) async child death notification via SIGCHLD
> c) these two signal handlers do nothing but raise volatile flags,
> all the
> work is done in the main loop
> d) locking no longer required
I cleaned up the rest of the comments, the whitespace and a few names to match
the whole thing. Please recheck it. Test script is switched to work on subsystem
'test' to let udev ignore it.
2004-02-07 09:21:15 +03:00
}
2004-04-01 11:03:46 +04:00
2006-08-05 15:22:44 +04:00
/* get control message */
2006-07-25 16:45:09 +04:00
if ( FD_ISSET ( udevd_sock , & readfds ) )
2006-08-05 15:22:44 +04:00
get_ctrl_msg ( ) ;
2005-06-05 06:38:10 +04:00
2006-08-05 15:22:44 +04:00
/* get netlink message */
2005-11-04 07:25:15 +03:00
if ( FD_ISSET ( uevent_netlink_sock , & readfds ) ) {
2005-06-16 03:58:47 +04:00
msg = get_netlink_msg ( ) ;
2005-11-07 04:22:44 +03:00
if ( msg )
2005-01-05 07:37:50 +03:00
msg_queue_insert ( msg ) ;
}
2004-04-01 11:03:46 +04:00
2005-08-08 07:07:36 +04:00
/* received a signal, clear our notification pipe */
2005-08-29 01:13:14 +04:00
if ( FD_ISSET ( signal_pipe [ READ_END ] , & readfds ) ) {
char buf [ 256 ] ;
read ( signal_pipe [ READ_END ] , & buf , sizeof ( buf ) ) ;
2005-08-15 13:57:04 +04:00
}
2004-04-01 11:03:46 +04:00
2005-10-27 23:04:38 +04:00
/* rules directory inotify watch */
2006-04-25 20:50:56 +04:00
if ( ( inotify_fd > = 0 ) & & FD_ISSET ( inotify_fd , & readfds ) ) {
2005-10-27 23:04:38 +04:00
int nbytes ;
/* discard all possible events, we can just reload the config */
if ( ( ioctl ( inotify_fd , FIONREAD , & nbytes ) = = 0 ) & & nbytes ) {
char * buf ;
reload_config = 1 ;
buf = malloc ( nbytes ) ;
if ( ! buf ) {
err ( " error getting buffer for inotify, disable watching " ) ;
close ( inotify_fd ) ;
inotify_fd = - 1 ;
}
read ( inotify_fd , buf , nbytes ) ;
free ( buf ) ;
}
}
/* rules changed, set by inotify or a signal*/
if ( reload_config ) {
reload_config = 0 ;
2006-01-09 23:18:00 +03:00
udev_rules_cleanup ( & rules ) ;
2005-11-05 22:00:31 +03:00
udev_rules_init ( & rules , 1 ) ;
2005-10-27 23:04:38 +04:00
}
2005-11-07 04:22:44 +03:00
/* forked child has returned */
2004-10-19 15:37:30 +04:00
if ( sigchilds_waiting ) {
sigchilds_waiting = 0 ;
reap_sigchilds ( ) ;
2004-04-01 11:03:07 +04:00
}
2004-04-01 11:03:46 +04:00
2004-04-01 11:03:07 +04:00
if ( run_exec_q ) {
run_exec_q = 0 ;
2005-06-05 06:41:09 +04:00
if ( ! stop_exec_q )
2005-11-07 16:10:09 +03:00
msg_queue_manager ( ) ;
[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 20:12:36 +03:00
}
}
2004-11-23 05:28:41 +03: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 20:12:36 +03:00
exit :
2006-01-09 23:18:00 +03:00
udev_rules_cleanup ( & rules ) ;
sysfs_cleanup ( ) ;
2005-10-27 23:04:38 +04:00
2006-04-25 20:50:56 +04:00
if ( signal_pipe [ READ_END ] > = 0 )
2005-08-28 22:25:37 +04:00
close ( signal_pipe [ READ_END ] ) ;
2006-04-25 20:50:56 +04:00
if ( signal_pipe [ WRITE_END ] > = 0 )
2005-08-28 22:25:37 +04:00
close ( signal_pipe [ WRITE_END ] ) ;
2005-08-11 22:34:24 +04:00
2006-04-25 20:50:56 +04:00
if ( udevd_sock > = 0 )
2005-08-08 07:07:36 +04:00
close ( udevd_sock ) ;
2006-04-25 20:50:56 +04:00
if ( inotify_fd > = 0 )
2005-10-27 23:04:38 +04:00
close ( inotify_fd ) ;
2006-04-25 20:50:56 +04:00
if ( uevent_netlink_sock > = 0 )
2005-08-08 07:07:36 +04:00
close ( uevent_netlink_sock ) ;
2004-10-19 05:15:10 +04:00
logging_close ( ) ;
2005-08-08 07:07:36 +04:00
2005-11-04 07:25:15 +03:00
return rc ;
[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 11:28:57 +03:00
}