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>
+ <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/>
+ <http://www.kroah.com/linux/talks/ols_2003_udev_talk/>
Q: How is udev related to devfs?
-A: udev works entirely in userspace, using /sbin/hotplug calls that the
- kernel makes whenever a device is added or removed from the kernel. All
- naming policy, and permission control is done in userspace. devfs
- operated from within the kernel.
+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 marked OBSOLETE if udev is not finished yet?
+Q: Why was devfs marked OBSOLETE/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 stoped maintaining
- the code.
+ - 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: If you really require this functionality, then use devfs. It is still
- present in the kernel.
+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: But wait, I really want udev to automatically load drivers when they
are not present but the device node is opened. It's the only reason I
like using devfs. Please make udev do this.
-A: No. udev is for managing /dev, not loading kernel drivers.
+A: No. udev is for managing /dev, not loading kernel drivers.
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
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. A
configuration file needs to be created to map the kernel default names
- to the devfs names. See the initial udev.conf.devfs file in the udev
- release. It is the start of such a configuration file. If there are
- any things missing, please let the udev authors know.
+ to the devfs names. See the udev.rules.devfs file in the udev
+ release.
+ Note that the devfs scheme is not recommended or officially supported
+ cause it is a really 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 disk rules for an example how to do it correctly in userspace
+ without any stupid device enumeration.
Q: What kinds of devices does udev create nodes for?
A: All devices that are shown in sysfs will work with udev. If more
of anonymous devices, udev will support it.
Q: Will udev support symlinks?
-A: Yes, It now does. Multiple symlinks per device node too.
-
-Q: How will udev support changes to device permissions?
-A: On shutdown, udev will save the state of existing device permissions to
- its database, and then used the on the next boot time.
+A: Yes, It now does. Multiple symlinks per device node are supported.
Q: How will udev handle the /dev filesystem?
-A: /dev can be a ramfs, or a backing filesystem. udev does not care what
- kind of filesystem it runs on.
+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 will be placed in initramfs and run for every device that is found.
- Work to get this implemented is still underway.
+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 into the desktop software.
+
+ 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 in 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>
+ <https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel>
Archives of the mailing list can be found at:
- <http://marc.theaimsgroup.com/?l=linux-hotplug-devel>
+ <http://marc.theaimsgroup.com/?l=linux-hotplug-devel>
~ianmdlvl / elogind.git / blobdiff