| 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 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 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. A |
| configuration file needs to be created to map the kernel default names |
| 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 |
| because 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 |
| support is added for devices to the kernel, udev will automatically |
| start working for them. All block devices are currently supported, and |
| almost all major char devices are supported. Kernel developers are |
| working on adding support for all char devices at this time. See the |
| linux-kernel mailing list for patches and status of these patches. |
| |
| 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: Will udev support symlinks? |
| A: Yes, It now does. 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 |
| |