X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=FAQ;h=2117a15fdfd3c3d655b413491f249f7fa6f4a961;hp=c082a5bec4d62fd443ee924f824090c3b90d0f0d;hb=33a5cc297680f20e791c792a45fe949f715f5f69;hpb=b1830e7984e86c5765a67a3aae4b63e1c48155b6 diff --git a/FAQ b/FAQ index c082a5bec..2117a15fd 100644 --- a/FAQ +++ b/FAQ @@ -1,75 +1,111 @@ 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: - + There is also a udev presentation given at OLS 2003 available at: - + 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 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: 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: But 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. Such a configuration file would be gladly added to - the udev package if it is provided by anyone who can create such a - mapping. +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 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. +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: Will udev support symlinks? -A: Yes, patches are gladly accepted to add this functionality. - -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. +Q: Does udev support symlinks? +A: Yes, 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 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 - - Archives of the mailing list can be found at: - + address for it is: + linux-hotplug@vger.kernel.org + Information on joining can be found at: + http://vger.kernel.org/vger-lists.html