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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
A second "add" event created a new enumeration with %e. Check the
udevdb first and if a matching name is already used.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Moving events directly to the exec queue instead of the reordering
incoming queue, leaves holes in the sequence, that lead to timeouts for
all other events. Remove that part of the special handling.
(With netlink, events can't get out-of-order and the maximum timeout is 5
seconds and should not cause any trouble with the 10 sec timout for the
firmware class anyway. Events with timeouts are still prioritized for
execution, but don't bypass the incoming queue anymore.)
Many thanks to:
Uberto Barbini <uberto@ubiland.net>
for his endless debugging and sending all the traces, that showed this
failure with his DVB device:
UEVENT[1124474094] add@/module/stv0299
UEVENT[1124474094] add@/module/ves1x93
UEVENT[1124474094] add@/module/ttpci_eeprom
UEVENT[1124474094] add@/module/saa7146
UEVENT[1124474094] add@/module/video_buf
UEVENT[1124474094] add@/module/saa7146_vv
UEVENT[1124474094] add@/module/dvb_core
UEVENT[1124474094] add@/module/dvb_ttpci
UEVENT[1124474094] add@/bus/pci/drivers/dvb
UEVENT[1124474094] add@/class/firmware/0000:00:14.0
UDEV [1124474094] add@/module/dvb_core
UDEV [1124474094] add@/module/saa7146_vv
UDEV [1124474094] add@/module/dvb_ttpci
UDEV [1124474094] add@/module/ves1x93
UDEV [1124474094] add@/module/ttpci_eeprom
UDEV [1124474094] add@/module/saa7146
UDEV [1124474094] add@/module/stv0299
UDEV [1124474094] add@/module/video_buf
UDEV [1124474094] add@/bus/pci/drivers/dvb
UEVENT[1124474094] remove@/class/firmware/0000:00:14.0 <- event with TIMEOUT will leave a hole in the incoming
UDEV [1124474094] add@/class/firmware/0000:00:14.0 sequence, which will cause a wait for the alarm()
UEVENT[1124474094] add@/class/i2c-adapter/i2c-1 that flushes the queue
UEVENT[1124474094] add@/class/i2c-dev/i2c-1
UDEV [1124474094] remove@/class/firmware/0000:00:14.0 <- event also has TIMEOUT and is executed immediately
UEVENT[1124474095] add@/class/dvb/dvb0.demux0
UEVENT[1124474095] add@/class/dvb/dvb0.dvr0
UEVENT[1124474095] add@/class/dvb/dvb0.video0
UEVENT[1124474095] add@/class/dvb/dvb0.audio0
UEVENT[1124474095] add@/class/dvb/dvb0.ca0
UEVENT[1124474095] add@/class/dvb/dvb0.osd0
UEVENT[1124474095] add@/class/dvb/dvb0.net0
UEVENT[1124474095] add@/class/video4linux/video1
UEVENT[1124474095] add@/class/dvb/dvb0.frontend0
UDEV [1124474099] add@/class/i2c-adapter/i2c-1 <- all others have 5 seconds delay cause of the missing event
UDEV [1124474099] add@/class/dvb/dvb0.ca0 missing events
UDEV [1124474099] add@/class/dvb/dvb0.osd0
UDEV [1124474099] add@/class/video4linux/video1
UDEV [1124474099] add@/class/dvb/dvb0.frontend0
UDEV [1124474099] add@/class/dvb/dvb0.video0
UDEV [1124474099] add@/class/dvb/dvb0.audio0
UDEV [1124474099] add@/class/i2c-dev/i2c-1
UDEV [1124474099] add@/class/dvb/dv
My test program that simulates a similar sequence, runs without any delay
now. (With one of the next versions we will make netlink mandatory, then
we can remove the whole input queue crap with the reordering anyway.)
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
No device node or symlink can have other characters as plain
readable ascii or valid utf8. The /dev/disk/by-label/* symlinks
can no longer contain weird stuff read from untrusted sources.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
We will not support any other character encoding than plain ascii
or utf8 for volume labels. All invalid utf8 and non-ascii characters
are substituted for security reasons. No options, no fancy heuristics.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
HAL soon wants to read the whole content of the udevdatabase while
starting up. This makes the whole udev structure available to the
udevinfo "dump".
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Just like the IMPORT values are stored in the udev database the
exported keys are stored in the udev database. The database is also
imported on a remove event before the rules are matched. So it
is possible to do:
ACTION=="add", KERNEL=="sda", ENV{MY_DEVICE}="1234", RUN+="/bin/logger add $devpath"
ACTION=="remove", ENV{MY_DEVICE}=="1234", RUN+="/bin/logger remove $devpath"
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
We want to write the output buffer before
we exit, otherwise redirection to a file
does not work correctly.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
If the kernel forks us as an usermodhelper, we don't have any of
the standard fd's and the first open() will start with fd=0.
This is inherited to all forked childs and confuses later forked
helpers where we want to read from a pipe connected to the helpers
stdout/stderr.
# ls -l /proc/$(pidof udevd)/fd
total 6
dr-x------ 2 root root 0 2005-08-18 12:44 .
dr-xr-xr-x 4 root root 0 2005-08-18 12:44 ..
lrwx------ 1 root root 64 2005-08-18 12:44 0 -> /dev/null
lrwx------ 1 root root 64 2005-08-18 12:44 1 -> socket:[1274617]
lr-x------ 1 root root 64 2005-08-18 12:44 2 -> pipe:[1274618]
l-wx------ 1 root root 64 2005-08-18 12:44 3 -> pipe:[1274618]
lrwx------ 1 root root 64 2005-08-18 12:44 4 -> socket:[1274619]
lrwx------ 1 root root 64 2005-08-18 12:44 5 -> socket:[1274620]
Ouch! This will obviously not redirect sterr, it will kill the pipe
we established between the parent and the child:
devnull = open("/dev/null", O_RDWR);
dup2(devnull, STDERR_FILENO);
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
vol_id segfaults if read() fails on broken devices reporting
the wrong size.
Thanks to Erhard Schultchen for the debugging.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
This can be uses to export stuff to the event environment or
to carry a state from one rule to another, like enabling/disabling
later rules conditionally.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Several people complained about the "default" rules and the "default"
setup. Here we start to remove things where we can't hava a "default".
The best examples for rules are in the distro folders, just pick the one
that matches your needs and start from there.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
