After long consideration we came to the conclusion that user
configuration in /etc should always override the (generally
computer generated) configuration in /run. User configuration
should always be what matters over anything else. Hence rearrange
the search orders accordingly. In general this should change
very little as overriding like this is seldomn done so far,
and the order between /etc and /usr stays the same.
<tomegun> kay: is this a valid issue: https://bugs.archlinux.org/task/27060 ?
<kay> tomegun: udev does not really care if that fails
<tomegun> kay: the suggestion there is to treat EINVAL the same way we treat ENOTTY (i.e. as an info only)
<tomegun> if it really does not matter it might make sense to avoid bogus bug reports
<kay> tomegun: done
Many servers will be connected to KVMs or include iLO support, and this
is often presented as a set of USB input devices. Enabling autosuspend on
these allows the USB hardware to be powered down, avoiding unnecessary
wakeups and power consumption. The input devices will be self powered, so
there's no risk of losing input events as there would be for real input
devices. The same is true of USB input devices that are built into the
system.
The use of identifying disks by magic byte sequences outside of the
filesystem or partion table is fragile and usually creates more
problems than it solves.
Udev-acl will be part of a future ConsoleKit release. On systemd systems,
advanced ConsoleKit and udev-acl functionality are natively provided by
systemd.
Udev does no longer automatically create udev rules in /etc from the
device hotplug path.
No device name reservation will happen anymore; this model creates
too many problems for setups with many device changes or media which
is booted on different hardware.
Enumerated device names which are based on device discovery order or
on persistent on-disk name reservation will in general not be supported
by udev in the future. It is a problem that can not be solved properly,
and it always creates new problems at the same time it tries to solve
the original one. Udev will no longer pretend it can solve these issues,
and people should switch to available alternatives which provide the
far better compromise.
From now on, udev will only create /dev/cdrom for the first optical
drive, and if the drive is capable /dev/dvd. No other devices will
get any compatibility symlinks or enumerated device names like cdrom1,
cdrom2, and so on. The /dev/cdrom and /dev/dvd links have by default
a negative link priority, which will cause them to be overwritten by
any other device which clains the same names with already existing
udev rules.
If stable device names are needed, the /dev/disk/by-id/ links, which
uniquely identify a specific piece of hardware should be used. The links
usually contain a device serial number and the link names will not depend
on device discovery order.
If completely identical devices with identical or no serial number
need to be handled at the same time, the /dev/disk/by-path/ links can
be used. These links depend on the physical port which is used to connect
the device. It will change when the same device is moved to a different
port or host adapter.
If custom names are needed, custom udev rules which match on specific
device properties need to be added by the administrator.
Device nodes might have been deleted again by the kernel before an
'add' or 'change' event is even started. We need to run all rules,
regardless of the state in /dev.
When we read the 'uevent' file we need to make sure, that we do not
read the relative DEVNAME= path provided by the kernel and overwrite
the absolute path udev expects here.
Kay Sievers
Matthew Garrett
Lucas De Marchi
Bruno Redondi
Andreas Schwab
James M. Leddy