mirror of
https://github.com/systemd/systemd.git
synced 2024-12-25 01:34:28 +03:00
The systemd System and Service Manager
bb38678e3c
There's still a slight race condition when using udevadm settle, if the udev daemon has a pending inotify event but hasn't yet generated the "change" uevent for it, the kernel and udev sequence numbers will match and settle will exit. Now udevadm settle will send a control message to udevd, which will respond by sending SIGUSR1 back to the waiting udevadm settle once it has completed the main loop iteration in which it received the control message. If there were no pending inotify events, this will simply wake up the udev daemon and allow settle to continue. If there are pending inotify events, they are handled first in the main loop so when settle is continued they will have been turned into uevents and the kernel sequence number will have been incremented. Since the inotify event is pending for udevd when the close() system call returns (it's queued as part of the kernel handling for that system call), and since the kernel sequence number is incremented by writing to the uevent file (as udevd does), this solves the race. When the settle continues, if there were pending inotify events that udevd had not read, they are now pending uevents which settle can wait for. Signed-off-by: Scott James Remnant <scott@ubuntu.com> |
||
|---|---|---|
| docs/writing_udev_rules | ||
| extras | ||
| m4 | ||
| rules | ||
| test | ||
| udev | ||
| .gitignore | ||
| autogen.sh | ||
| ChangeLog | ||
| configure.ac | ||
| COPYING | ||
| INSTALL | ||
| Makefile.am | ||
| Makefile.am.inc | ||
| NEWS | ||
| README | ||
| TODO | ||
| udev.conf | ||
udev - userspace device management
For more information see the files in the docs/ directory.
Important Note:
Integrating udev in the system has complex dependencies and differs from distro
to distro. All major distros depend on udev these days and the system may not
work without a properly installed version. The upstream udev project does not
recommend to replace a distro's udev installation with the upstream version.
Requirements:
- Version 2.6.22 of the Linux kernel for reliable operation of this release of
udev. The kernel must not use the CONFIG_SYSFS_DEPRECATED* option.
- The kernel must have sysfs, unix domain sockets and networking enabled.
Unix domain sockets (CONFIG_UNIX) as a loadable kernel module is not
supported.
- The proc filesystem must be mounted on /proc/, the sysfs filesystem must
be mounted at /sys/. No other locations are supported by udev.
- The system must have the following group names resolvable at udev startup:
disk, cdrom, floppy, tape, audio, video, lp, tty, dialout, kmem.
Especially in LDAP setups, it is required, that getgrnam() is able to resolve
these group names with only the rootfs mounted, and while no network is
available.
Operation:
Udev creates and removes device nodes in /dev/, based on events the kernel
sends out on device discovery or removal.
- Very early in the boot process, the /dev/ directory should get a 'tmpfs'
filesystem mounted, which is populated from scratch by udev. Created nodes
or changed permissions will not survive a reboot, which is intentional.
- The content of /lib/udev/devices/ directory which contains the nodes,
symlinks and directories, which are always expected to be in /dev, should
be copied over to the tmpfs mounted /dev, to provide the required nodes
to initialize udev and continue booting.
- The old hotplug helper /sbin/hotplug should be disabled on bootup, before
actions like loading kernel modules are taken, which may cause a lot of
events.
- The udevd daemon must be started on bootup to receive netlink uevents
from the kernel driver core.
- All kernel events are matched against a set of specified rules in
/lib/udev/rules.d/ which make it possible to hook into the event
processing to load required kernel modules and setup devices. For all
devices the kernel exports a major/minor number, udev will create a
device node with the default kernel name, or the one specified by a
matching udev rule.
Please direct any comment/question/concern to the linux-hotplug mailing list at:
linux-hotplug@vger.kernel.org