FAQ: update things that have changed

Signed-off-by: Kay Sievers <kay.sievers@suse.de>

1 files changed, 49 insertions, 43 deletions

diff --git a/FAQ b/FAQ
index bd9d63a4d5..1b9e56d8c5 100644
--- a/FAQ
+++ b/FAQ
@@ -1,40 +1,40 @@
 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>
+     <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/>
+     <http://www.kroah.com/linux/talks/ols_2003_udev_talk/>
 
 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 stopped 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: 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: No. udev is for managing /dev, not loading kernel drivers.
 
 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
@@ -53,9 +53,14 @@ A: The devfs approach caused a lot of spurious modprobe attempts as
 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.
+   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
@@ -70,29 +75,30 @@ 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.
+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. Projects that do
-   automount hotplugged storage devices are:
-     * Usb-mount http://users.actrix.co.nz/michael/usbmount.html
-     * devlabel http://linux.dell.com/projects.shtml#devlabel   
-                                                             
-   Alternatively, it is easy to add the following to fstab:  
-   /udev/pendrive       /pendrive       vfat    user,noauto             0       0
+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 /pendrive
-   And don't have to be root but will get full permissions on /pendrive.
-   This works even without udev if /udev/pendrive is replaced by /dev/sda1
+     $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
@@ -103,15 +109,15 @@ A: When using dynamic device numbers, a given pair of major/minor numbers may
    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 (tmpfs, ramfs, ...).
-    
+   /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
-	<https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel>
+      <https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel>
    Archives of the mailing list can be found at:
-	<http://marc.theaimsgroup.com/?l=linux-hotplug-devel>
+      <http://marc.theaimsgroup.com/?l=linux-hotplug-devel>