From: Kay Sievers Date: Mon, 1 Sep 2008 14:40:31 +0000 (+0200) Subject: remove FAQ X-Git-Tag: 174~1603 X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=commitdiff_plain;h=71ac635d7747d6c1d610d0df9f57182aee3f1cdc remove FAQ --- diff --git a/FAQ b/FAQ deleted file mode 100644 index 2117a15fd..000000000 --- a/FAQ +++ /dev/null @@ -1,111 +0,0 @@ -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 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 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. 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 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: Does udev support symlinks? -A: Yes, 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@vger.kernel.org - Information on joining can be found at: - http://vger.kernel.org/vger-lists.html -