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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Syslog wants to distinguish the sorce of messages. We should
indicate that this is a userspace message (LOG_DAEMON) and not
a kernel message (LOG_KERNEL).
We need to preserve the database of network interfaces while we
rename them. Use the kernel's numbers wherever possible, instead
of the device names.
Fix wrong database filenames which contain a '/', translated
from '!' in the kernel name.
Fix segfault for kobject pathes where the subsystem can not be
determined from sysfs.
<Md> kay: can you look at rename_netif()? it returns -errno in a place,
but I think that it may by changed by err() (at least)
<kay> Md: yeah, that doesn't look correct
Harald Hoyer discovered some incorrect behavior while debugging
problems with network interface renaming:
Udev events might be queued for devices which are renamed. A new
device registered the same time may claime the old name and create
a database entry for it. The current rename logic would move over
this databse entry to the wrong device.
e.g. if eth0 should be eth3 and eth3 is waiting to be renamed,
eth0 was renamed to eth0_rename. The kernel would take eth0 as the name
for a new interface and this new eth0 could also become eth0_rename, if
the target name is also taken. To prevent this name clash, the
interfaces are now renamed to <src>-<dest> and the rename is logged.
There is no way to ignore an event these days. Libudev events can
not be suppressed. It only prevents RUN keys from being executed,
which results in an inconsistent behavior in current setups.
With well defined and kernel-supplied node names, we no longer need
to support a possible stack of conflicting symlinks and node names.
Only symlinks with identical names can be claimed by multiple devices.
This shrinks the former /dev/.udev/names/ significantly.
Also the /dev/{block,char}/MAJ:MIN" links are excluded from the name
stack - they are unique and can not conflict.
External programs triggered by events (via RUN=) will inherit udev's
signal mask, which is set to block all but SIGALRM. For most utilities,
this is OK, but if we start daemons from RUN=, we run into trouble
(especially as SIGCHLD is blocked).
This change saves the original sigmask when udev starts, and restores it
just before we exec() the external command.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
POSIX.1-2001 declares usleep() function obsolete and POSIX.1-2008
removes it.
[Kay Sievers]
- include time.h
- use const for timespec
- scsi_id: drop rand() in retry loop
- modem-probe: rename msuspend() to msleep()
With very deeply nested devices, We can not use a single file
name to carry an entire DEVPATH. Use <subsystem>:<sysname> as
the database filename, which should also simplify the handling
of devices moving around, as these values will not change but
still be unique.
For the name stack we use the <maj>:<min> now as the filename.
> On Tue, Aug 18, 2009 at 09:59:56AM -0400, Ric Wheeler wrote:
> The first is that udev grumbles during boot about "file name too long"
> like the following:
>
> Aug 17 06:49:58 megadeth udevd-event[20447]: unable to create db file
> '/dev/.udev/db/\x2fdevices\x2fpci0000:00\x2f0000:00:04.0\x2f0000:17:00.0\x2f0000:18:0a.0\x2f0000:1f:00.0\x2fhost11\x2fport-11:0\x2fexpander-11:0\x2fport-11:0:0\x2fexpander-11:1\x2fport-11:1:0\x2fexpander-11:2\x2fport-11:2:17\x2fexpander-11:3\x2fport-11:3:1\x2fend_device-11:3:1\x2fbsg\x2fend_device-11:3:1':
> File name too long
Fix spelling in docbook comments, code comments, and a local variable
name. Thanks to "ispell -h" for docbook HTML and "scspell" for source
code.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
It did not work for the last couple of releases.
If RUN{record_failed}+="..." is given, a non-zero execution will mark
the event as failed. Recorded failed events can be re-triggered with:
udevadm trigger --type=failed
The failed tracking _might_ be useful for things which might not be
ready to be executed at early bootup, but a bit later when the needed
dependencies are available. In many cases though, it indicates that
something is used in a way it should not.
