chiark / gitweb /
udevd: fix udevd read() calls to leave room for null byte
[elogind.git] / FAQ
1 Frequently Asked Questions about udev
2
3 Q: What's this udev thing, and what is it trying to do?
4 A: Read the OLS 2003 paper about udev, available in the docs/ directory,
5    and at:
6      <http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf>
7    There is also a udev presentation given at OLS 2003 available at:
8      <http://www.kroah.com/linux/talks/ols_2003_udev_talk/>
9
10 Q: How is udev related to devfs?
11 A: udev works entirely in userspace, using hotplug events the kernel sends
12    whenever a device is added or removed from the kernel. Details about
13    the devices are exported by the kernel to the sysfs filesystem at /sys
14    All device naming policy permission control and event handling is done in
15    userspace. devfs is operated from within the kernel.
16
17 Q: Why was devfs marked OBSOLETE/removed if udev can't do everthing devfs did?
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: Right, but Linux is supposed to load a module when a device is discovered
32    not to load a module when it's accessed.
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  udev.rules.devfs file in the udev
57    release.
58    Note that the devfs scheme is not recommended or officially supported
59    cause it is a really stupid idea to simply enumerate devices in a world
60    where devices can come and go at any time. These numbers give you nothing
61    but problems, and are not useful to identify a device. Have a look at the
62    persistent disk rules for an example how to do it correctly in userspace
63    without any stupid device enumeration.
64
65 Q: What kinds of devices does udev create nodes for?
66 A: All devices that are shown in sysfs will work with udev.  If more
67    support is added for devices to the kernel, udev will automatically
68    start working for them.  All block devices are currently supported, and
69    almost all major char devices are supported.  Kernel developers are
70    working on adding support for all char devices at this time.  See the
71    linux-kernel mailing list for patches and status of these patches.
72
73 Q: Will udev remove the limit on the number of anonymous devices?
74 A: udev is entirely in userspace.  If the kernel supports a greater number
75    of anonymous devices, udev will support it.
76
77 Q: Will udev support symlinks?
78 A: Yes, It now does.  Multiple symlinks per device node are supported.
79
80 Q: How will udev handle the /dev filesystem?
81 A: /dev is recomended to be a tmpfs filesystem that is recreated on every reboot.
82    Although, udev does not care what kind of filesystem it runs on.
83
84 Q: How will udev handle devices found before init runs?
85 A: udev can be placed in initramfs and run for every device that is found.
86    udev can also populate an initial /dev directory from the content of /sys
87    after the real root is mounted.
88
89 Q: Can I use udev to automount a USB device when I connect it?
90 A: Technically, yes, but udev is not intended for this. All major distributions
91    use HAL (http://freedesktop.org/wiki/Software_2fhal) for this, which also
92    watches devices with removable media and integrates into the desktop software.
93
94    Alternatively, it is easy to add the following to fstab:
95      /dev/disk/by-label/PENDRIVE /media/PENDRIVE  vfat user,noauto 0 0
96
97    This means that users can access the device with:
98      $mount /media/PENDRIVE
99    and doen't have to be root, but will get full permissions on the device.
100    Using the persistent disk links (label, uuid) will always catch the
101    same device regardless of the actual kernel name.
102
103 Q: Are there any security issues that I should be aware of?
104 A: When using dynamic device numbers, a given pair of major/minor numbers may
105    point to different hardware over time. If a user has permission to access a
106    specific device node directly and is able to create hard links to this node,
107    he or she can do so to create a copy of the device node. When the device is
108    unplugged and udev removes the device node, the user's copy remains.
109    If the device node is later recreated with different permissions the hard 
110    link can still be used to access the device using the old permissions.
111    (The same problem exists when using PAM to change permissions on login.)
112
113    The simplest solution is to prevent the creation of hard links by putting
114    /dev in a separate filesystem like tmpfs.
115
116 Q: I have other questions about udev, where do I ask them?
117 A: The linux-hotplug-devel mailing list is the proper place for it.  The
118    address for it is linux-hotplug-devel@lists.sourceforge.net
119    Information on joining can be found at
120       <https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel>
121    Archives of the mailing list can be found at:
122       <http://marc.theaimsgroup.com/?l=linux-hotplug-devel>
123