mirror of
https://github.com/systemd/systemd.git
synced 2024-11-05 06:52:22 +03:00
112 lines
5.6 KiB
Plaintext
112 lines
5.6 KiB
Plaintext
Frequently Asked Questions about udev
|
|
|
|
Q: What's this udev thing, and what is it trying to do?
|
|
A: Read the OLS 2003 paper about udev, available in the docs/ directory,
|
|
and at:
|
|
<http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf>
|
|
There is also a udev presentation given at OLS 2003 available at:
|
|
<http://www.kroah.com/linux/talks/ols_2003_udev_talk/>
|
|
|
|
Q: How is udev related to devfs?
|
|
A: udev works entirely in userspace, using hotplug events the kernel sends
|
|
whenever a device is added or removed from the kernel. Details about
|
|
the devices are exported by the kernel to the sysfs filesystem at /sys
|
|
All device naming policy permission control and event handling is done in
|
|
userspace. devfs is operated from within the kernel.
|
|
|
|
Q: Why was devfs removed if udev can't do everthing devfs did?
|
|
A: To quote Al Viro (Linux VFS kernel maintainer):
|
|
- it was determined that the same thing could be done in userspace
|
|
- devfs had been shoved into the tree in hope that its quality will
|
|
catch up
|
|
- devfs was found to have fixable and unfixable bugs
|
|
- the former had stayed around for many months with maintainer
|
|
claiming that everything works fine
|
|
- the latter had stayed, period.
|
|
- the devfs maintainer/author disappeared and stopped maintaining
|
|
the code.
|
|
|
|
Q: But udev will not automatically load a driver if a /dev node is opened
|
|
when it is not present like devfs will do.
|
|
A: Right, but Linux is supposed to load a module when a device is discovered
|
|
not to load a module when it's accessed.
|
|
|
|
Q: Oh come on, pretty please. It can't be that hard to do.
|
|
A: Such a functionality isn't needed on a properly configured system. All
|
|
devices present on the system should generate hotplug events, loading
|
|
the appropriate driver, and udev will notice and create the
|
|
appropriate device node. If you don't want to keep all drivers for your
|
|
hardware in memory, then use something else to manage your modules
|
|
(scripts, modules.conf, etc.) This is not a task for udev.
|
|
|
|
Q: But I love that feature of devfs, please?
|
|
A: The devfs approach caused a lot of spurious modprobe attempts as
|
|
programs probed to see if devices were present or not. Every probe
|
|
attempt created a process to run modprobe, almost all of which were
|
|
spurious.
|
|
|
|
Q: I really like the devfs naming scheme, will udev do that?
|
|
A: Yes, udev can create /dev nodes using the devfs naming policy. But you
|
|
will need a custom configuration and scripts that enumerate your devices
|
|
sequentially while events run in parallel, without a predictable order.
|
|
The devfs scheme is not recommended or supported because it is a stupid
|
|
idea to simply enumerate devices in a world where devices can come and go
|
|
at any time. These numbers give you nothing but problems, and are not
|
|
useful to identify a device. Have a look at the persistent rules for
|
|
examples how to create persistent device names in userspace without any
|
|
device enumeration depending on the device probing order.
|
|
|
|
Q: What kinds of devices does udev create nodes for?
|
|
A: All devices that are shown in the kernel's sysfs tree will work with udev.
|
|
|
|
Q: Will udev remove the limit on the number of anonymous devices?
|
|
A: udev is entirely in userspace. If the kernel supports a greater number
|
|
of anonymous devices, udev will support it.
|
|
|
|
Q: Does udev support symlinks?
|
|
A: Yes, multiple symlinks per device node are supported.
|
|
|
|
Q: How will udev handle the /dev filesystem?
|
|
A: /dev is recomended to be a tmpfs filesystem that is recreated on every reboot.
|
|
Although, udev does not care what kind of filesystem it runs on.
|
|
|
|
Q: How will udev handle devices found before init runs?
|
|
A: udev can be placed in initramfs and run for every device that is found.
|
|
udev can also populate an initial /dev directory from the content of /sys
|
|
after the real root is mounted.
|
|
|
|
Q: Can I use udev to automount a USB device when I connect it?
|
|
A: Technically, yes, but udev is not intended for this. All major distributions
|
|
use HAL (http://freedesktop.org/wiki/Software_2fhal) for this, which also
|
|
watches devices with removable media and integrates the Desktop environment.
|
|
|
|
Alternatively, it is easy to add the following to fstab:
|
|
/dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0
|
|
|
|
This means that users can access the device with:
|
|
$mount /media/PENDRIVE
|
|
and doen't have to be root, but will get full permissions on the device.
|
|
Using the persistent disk links (label, uuid) will always catch the
|
|
same device regardless of the actual kernel name.
|
|
|
|
Q: Are there any security issues that I should be aware of?
|
|
A: When using dynamic device numbers, a given pair of major/minor numbers may
|
|
point to different hardware over time. If a user has permission to access a
|
|
specific device node directly and is able to create hard links to this node,
|
|
he or she can do so to create a copy of the device node. When the device is
|
|
unplugged and udev removes the device node, the user's copy remains.
|
|
If the device node is later recreated with different permissions the hard
|
|
link can still be used to access the device using the old permissions.
|
|
(The same problem exists when using PAM to change permissions on login.)
|
|
|
|
The simplest solution is to prevent the creation of hard links by putting
|
|
/dev on a separate filesystem like tmpfs.
|
|
|
|
Q: I have other questions about udev, where do I ask them?
|
|
A: The linux-hotplug-devel mailing list is the proper place for it. The
|
|
address for it is:
|
|
linux-hotplug-devel@lists.sourceforge.net
|
|
Information on joining can be found at:
|
|
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
|
|
|