X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=FAQ;h=2117a15fdfd3c3d655b413491f249f7fa6f4a961;hp=a3bec17408f2e722fbe2155326faebb51bca8148;hb=da8ba809e1f846353da8f53b62741fe13d0b021c;hpb=786f9231961cc12e59cce3e3ad117ad976adf6f5 diff --git a/FAQ b/FAQ index a3bec1740..2117a15fd 100644 --- a/FAQ +++ b/FAQ @@ -1,40 +1,35 @@ 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. - -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: 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 @@ -51,44 +46,66 @@ A: The devfs approach caused a lot of spurious modprobe attempts as 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.rules.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. +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, 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. +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