FAQ

   1 Frequently Asked Questions about udev
   2
   3
   4 Q: What's this udev thing, and what is it trying to do?
   5 A: Read the OLS 2003 paper about udev, available in the docs/ directory,
   6    and at:
   7         <http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf>
   8    There is also a udev presentation given at OLS 2003 available at:
   9         <http://www.kroah.com/linux/talks/ols_2003_udev_talk/>
  10
  11 Q: How is udev related to devfs?
  12 A: udev works entirely in userspace, using /sbin/hotplug calls that the
  13    kernel makes whenever a device is added or removed from the kernel.  All
  14    naming policy, and permission control is done in userspace.  devfs
  15    operated from within the kernel.
  16
  17 Q: Why was devfs marked OBSOLETE if udev is not finished yet?
  18 A: To quote Al Viro (Linux VFS kernel maintainer):
  19         - it was determined that the same thing could be done in userspace
  20         - devfs had been shoved into the tree in hope that its quality will
  21           catch up
  22         - devfs was found to have fixable and unfixable bugs
  23         - the former had stayed around for many months with maintainer
  24           claiming that everything works fine
  25         - the latter had stayed, period.
  26         - the devfs maintainer/author disappeared and stopped maintaining
  27           the code.
  28
  29 Q: But udev will not automatically load a driver if a /dev node is opened
  30    when it is not present like devfs will do.
  31 A: If you really require this functionality, then use devfs.  It is still
  32    present in the kernel.
  33
  34 Q: But wait, I really want udev to automatically load drivers when they
  35    are not present but the device node is opened.  It's the only reason I
  36    like using devfs.  Please make udev do this.
  37 A: No.  udev is for managing /dev, not loading kernel drivers.
  38
  39 Q: Oh come on, pretty please.  It can't be that hard to do.
  40 A: Such a functionality isn't needed on a properly configured system. All
  41    devices present on the system should generate hotplug events, loading
  42    the appropriate driver, and udev will notice and create the
  43    appropriate device node.  If you don't want to keep all drivers for your
  44    hardware in memory, then use something else to manage your modules
  45    (scripts, modules.conf, etc.)  This is not a task for udev.
  46
  47 Q: But I love that feature of devfs, please?
  48 A: The devfs approach caused a lot of spurious modprobe attempts as
  49    programs probed to see if devices were present or not.  Every probe
  50    attempt created a process to run modprobe, almost all of which were
  51    spurious.
  52
  53 Q: I really like the devfs naming scheme, will udev do that?
  54 A: Yes, udev can create /dev nodes using the devfs naming policy.  A
  55    configuration file needs to be created to map the kernel default names
  56    to the devfs names.  See the initial udev.rules.devfs file in the udev
  57    release.  It is the start of such a configuration file.  If there are
  58    any things missing, please let the udev authors know.
  59
  60 Q: What kinds of devices does udev create nodes for?
  61 A: All devices that are shown in sysfs will work with udev.  If more
  62    support is added for devices to the kernel, udev will automatically
  63    start working for them.  All block devices are currently supported, and
  64    almost all major char devices are supported.  Kernel developers are
  65    working on adding support for all char devices at this time.  See the
  66    linux-kernel mailing list for patches and status of these patches.
  67
  68 Q: Will udev remove the limit on the number of anonymous devices?
  69 A: udev is entirely in userspace.  If the kernel supports a greater number
  70    of anonymous devices, udev will support it.
  71
  72 Q: Will udev support symlinks?
  73 A: Yes, It now does.  Multiple symlinks per device node too.
  74
  75 Q: How will udev handle the /dev filesystem?
  76 A: /dev can be a ramfs, or a backing filesystem.  udev does not care what
  77    kind of filesystem it runs on.
  78
  79 Q: How will udev handle devices found before init runs?
  80 A: udev will be placed in initramfs and run for every device that is found.
  81    Work to get this implemented is still underway.
  82
  83 Q: Can I use udev to automount a USB device when I connect it?
  84 A: Technically, yes, but udev is not intended for this. Projects that do
  85    automount hotplugged storage devices are:
  86      * Usb-mount http://users.actrix.co.nz/michael/usbmount.html
  87      * devlabel http://linux.dell.com/projects.shtml#devlabel
  88
  89    Alternatively, it is easy to add the following to fstab:
  90    /udev/pendrive       /pendrive       vfat    user,noauto             0       0
  91
  92    This means that users can access the device with:
  93    $ mount /pendrive
  94    And don't have to be root but will get full permissions on /pendrive.
  95    This works even without udev if /udev/pendrive is replaced by /dev/sda1
  96
  97 Q: Are there any security issues that I should be aware of?
  98 A: When using dynamic device numbers, a given pair of major/minor numbers may
  99    point to different hardware over time. If a user has permission to access a
 100    specific device node directly and is able to create hard links to this node,
 101    he or she can do so to create a copy of the device node. When the device is
 102    unplugged and udev removes the device node, the user's copy remains.
 103    If the device node is later recreated with different permissions the hard
 104    link can still be used to access the device using the old permissions.
 105    (The same problem exists when using PAM to change permissions on login.)
 106
 107    The simplest solution is to prevent the creation of hard links by putting
 108    /dev in a separate filesystem (tmpfs, ramfs, ...).
 109
 110 Q: I have other questions about udev, where do I ask them?
 111 A: The linux-hotplug-devel mailing list is the proper place for it.  The
 112    address for it is linux-hotplug-devel@lists.sourceforge.net
 113    Information on joining can be found at
 114         <https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel>
 115    Archives of the mailing list can be found at:
 116         <http://marc.theaimsgroup.com/?l=linux-hotplug-devel>
 117