mirror of
https://github.com/AuxXxilium/eudev.git
synced 2024-12-15 02:56:51 +07:00
FAQ: update things that have changed
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
This commit is contained in:
parent
a8b38f1c44
commit
9d97f3bb79
92
FAQ
92
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>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user