X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=FAQ;h=28f7552ae3c557b906596394f64b38f88c3bd274;hp=c082a5bec4d62fd443ee924f824090c3b90d0f0d;hb=84df02dd63bf53acb5a61e9db1da067760b927e9;hpb=b1830e7984e86c5765a67a3aae4b63e1c48155b6

diff --git a/FAQ b/FAQ
index c082a5bec..28f7552ae 100644
--- a/FAQ
+++ b/FAQ
@@ -31,12 +31,31 @@ Q: But udev will not automatically load a driver if a /dev node is opened
 A: If you really require this functionality, then use devfs.  It is still
    present in the kernel.
 
-Q: But I really like the devfs naming scheme, will udev do that?
+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.
+
+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.  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 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.
 
 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,7 +70,7 @@ 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.
+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
@@ -65,6 +84,20 @@ 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.
 
+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
+
+   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
+
 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