X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=FAQ;h=abe88638b212b85fc01fa4c595a3ebd7358cfc0a;hp=c082a5bec4d62fd443ee924f824090c3b90d0f0d;hb=e4b1a0f608c2d00e458b5cb47a6fba4da9aafe7e;hpb=b1830e7984e86c5765a67a3aae4b63e1c48155b6 diff --git a/FAQ b/FAQ index c082a5bec..abe88638b 100644 --- a/FAQ +++ b/FAQ @@ -1,42 +1,61 @@ 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 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: 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? +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. Such a configuration file would be gladly added to - the udev package if it is provided by anyone who can create such a - mapping. + 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 @@ -51,25 +70,49 @@ 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. +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 - + Archives of the mailing list can be found at: - +