IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If we take over the hotplug call and manage the events we don't need
to call the event fake script in dev.d/. Just set all expected values
to the new network interface name and call hotplug.d/. This way the
device renaming is completely handled inside of udev and userspace
can't get confused.
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.
Make _all_ hotplug variables available to the forked udev,
the udev callouts and the udev dev.d/ scripts. We put the
whole environment into a buffer and send it over the udevd
socket. udevd recreates *envp[] and passes it to the exec().
Change to the same timeout loop we use in the rest of the code. Change
some comments and names to be more descriptive.
I'm mostly finished with the overall cleanup. I will post a new patch
for the udevd-nofork experiment, which will be much smaller now.
This patch fixes the reintroduced bug with the
sig_handler(), if we link against a -mregparm=3 compiled
klibc on i386.
It also fixes some compiler warnings about redefined
asmlinkage on some systems.
Also some (broken?) compilers on distros throw out warnings
if asmlinkage is before "static void". This fixes it, too.
This patch fixes two
warning: assignment from incompatible pointer type
asmlinkage is the reason for the warning. We can
simply cast to avoid it.
It also fixes this warning:
warning: implicit declaration of function `umask'
here we change udevd to pass the SEQNUM from the hotplug environment
to udev and the dev.d/ scripts. We need this for HAL to match the
hotplug event with the dev.d/ events.
It also changes the type from int to long to match the kernel.
The following patch adds 'asmlinkage' defines to udev, to kill off 2
warnings on !i386.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The recent version of klibc switched to -mregparm=3. This broke the
signal handlers parameter, cause it is called directly from the kernel
with the parameter on the stack not in a register.
Thanks to Yin, Hu <hu.yin@intel.com>, who made a nice perl script to test the
expected behavior of the udevd sequence number handling. The test sends
different SEQNUM sequences to udevd, while analyzing the reordering and timeout
handling of udevd.
Here we change the DEVPATH for netdev's in the environment of the dev.d/
scripts to the name the device is renamed to. The original name doesn't
exist in the kernel after rename.
here is a patch on top of your nice improvements.
I fixed the whitespace and it hopefully fixes the stupid timestamp bug in
udevd. Some stupid OS sets the hwclock to localtime and linux changes it
to UTC while starting. If any events are pending they may be delayed by
the users time distance from UTC :) So we use the uptime seconds now.
This patch covers a number of areas:
1) sysfs.h is fixed up to use the common dbg() macro. This fixes the
case where DEBUG is defined but USE_LOG isn't.
2) udevstart.c is modified to include the proper headers, rather than
getting them indirectly which can break depending on Makefile flags
3) udevd.c gets some major changes:
a) I added a pipe from the signal handler. This fixes the race
conditions that I mentioned earlier. Basically, the point of the pipe
is to force the select() call to return immediately if a signal handler
fired before we actually started the select() call. This then lets us
run the appropriate code based on flags set in the signal handler proper.
b) I added a number of flags to coalesce calls to common routines. This
should make things slightly more efficient.
c) since most calls will tend to come in with a sequence number larger
than what has been received, I switched msg_queue_insert() to scan the
msg_list backwards to improve performance.
filename="udevd.diff"
On Thu, Mar 25, 2004 at 02:52:13AM +0100, Kay Sievers wrote:
> Please have look if it still works for you, I only did a very quick
> test.
Here is a unified version, with all the functions moved to udev_lib.c.
We have a generic function now, to call a given fnct(char *) for every
file ending with a specific suffix, sorted in lexical order. We use it
to execute the dev.d/ files and read our rules.d/ files. The binary
should be a bit smaller now.
I've also changed it, to not do the dev.d/ exec for net devices.
Here we replace the various fgets() with a mmap() call for the config
file reading, due to the reported performance problems with klibc.
Thanks to Patrick's testing, it makes a very small, close to nothing
speed gain for libc users, but a 6 times speed increase for klibc users
with a 1000 line config file.
I've created a udev_lib.[hc] for this and also moved all the generic
stuff from udev.h in there and uninlined the functions.
Here I try to make the style a bit more consistant in the different
files, so that new patches just copy the 'right' one :)
Some "magic" numbers are replaced and udevtest.c is catched up with udev.
Here we truncate our input strings from the environment to our
defined limit. It's a bit theroretical but better check for it.
It cleans up some magic length definitions and removes the code
duplication in udev, udevtest and udevsend.
udevd needs to be killed after installation, cause the message size
is changed with this patch.
Should we do this with the 'make install', like we do with the '.udevdb'?
Here is a small improvement. We check for the type of message we receive
and udevsend seems not to need all the credential setup stuff, the
kernel will fill it for us.
udevd now refuses to start as non root, cause it doesn't make any sense.
Here is the badly needed client authorization for udevd.
Since we switched to abstract namespace sockets, we are unable to
control the access of the socket by file permissions.
So here we send a ancillary credential message with every datagram,
to be able to verify the uid of the sender. The sender can't fake the
credentials, cause the kernel doesn't allow it for non root users.
udevd is still working with klibc here :)
On Mon, Feb 09, 2004 at 05:41:15AM +0100, Kay Sievers wrote:
> It seems that today was just another udev-sunday for me :)
>
> Here is a working patch to compile udevd with klibc.
>
> It's sweet the static binary takes 6 kbytes and it runs
> with only 80 kbytes virtual memory.
>
> I changed a few peaces and added a siginterrupt.c file to klibc.
> We may check with hpa to get the changes upstream?
So here is the next try :)
hpa, for good reason, didn't like my changes to klibc.
He will dump signal() completely from klibc instead, so here we switch to
sigaction() and keep udevd working with klibc.
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.
It seems that the guys are no longer differ about the right size of the
socket address :)
The kernel simply takes all bytes until the specified length as the name,
so the real length should be enough.
As Chris Friesen <chris_friesen@sympatico.ca> suggested, here we switch
the unix domains socket path to abstract namespace and get rid of the
socket file in the filesystem.
Hey, this was new to me today. So here a few words:
Linux supports a abstract namespace for sockets. We don't need a
physical file on the filesystem but only a unique string magically
starting with the '\0' character.
strace with real file:
connect(3, {sa_family=AF_UNIX, path="/udev/.udevd.sock"}, 110)
strace with abstract namespace:
connect(3, {sa_family=AF_UNIX, path=@udevd}, 110)
This patch allows udevsend to be called by the user and not only by the
kernel with its SEQNUM. If no SEQNUM is given, we move the event straight
to the exec queue and don't look if something is missing.
I don't know if this is really needed, but some people seem trying to
send events trough udevd instead of calling udev directly with their
scripts and confuse the reorder logic with that.
So at least, we may remove this source of confusion and udevsend is much
much faster back than udev itself and it will also block concurrent events
for the same devpath.
> Here is a small cleanup and better Makefile integration.
> udevd and udevsender are now installed. Just switch HOTPLUG_EXEC from ROOT
> to SENDER before install and udevsend will be called.
>
> We may add the location of the socket and lock file to the config,
> if this is needed.
Same patch with a fix for the stack size setting.
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.
