FAQ - pub/scm/linux/hotplug/udev - Git at Google

 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>
    There is also a udev presentation given at OLS 2003 available at:
      <http://www.kroah.com/linux/talks/ols_2003_udev_talk/>

 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
	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>
	There is also a udev presentation given at OLS 2003 available at:
	<http://www.kroah.com/linux/talks/ols_2003_udev_talk/>

	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