Libudev
| Developer(s) | Greg Kroah-Hartman and Kay Sievers |
|---|---|
| Initial release | November 2003 |
| Stable release | 233 (March 1, 2017) |
| Preview release | 230 (May 21, 2016) |
| Repository | git |
| Written in | C |
| Operating system | Linux kernel |
| Type | Device node |
| License | GPL v2 |
| Website | www |
udev (userspace /dev) is a device manager for the Linux kernel. As the successor of devfsd and hotplug, udev primarily manages device nodes in the /dev directory. At the same time, udev also handles all user space events raised when hardware devices are added into the system or removed from it, including firmware loading as required by certain devices.
It is an operating system's kernel that is responsible for providing an abstract interface of the hardware to the rest of the software. Being a monolithic kernel, the Linux kernel does exactly that, and device drivers are part of the Linux kernel, which make up more than 50% of its source code. Hardware can be accessed through system calls or over their device nodes.
To be able to deal with peripheral devices that are hotplug-capable in a user-friendly way, a part of handling all of these hotplug-capable hardware devices was handed over from the kernel to a daemon running in user-space. Running in user space serves security and stability purposes.
Device drivers are part of the Linux kernel, and device discovery, state changes, etc. are handled by the Linux kernel. But after loading the driver into memory, the only action the kernel takes is to send out an event to a userspace daemon udevd. It is the device manager, udevd, that catches all of these events and then decides what shall happen next. For this, udevd has a very comprehensive set of configuration files, which can all be adjusted by the computer administrator, according to their needs.
The complexity of doing so forces application authors to re-implement hardware support logic. Some hardware devices also require privileged helper programs to prepare them for use. These must often be invoked in ways that can be awkward to express with the Unix permissions model (for example, allowing users to join wireless networks only if they are logged into the video console). Application authors resort to using setuid binaries or run service daemons to provide their own access control and privilege separation, potentially introducing security holes each time.
...
Wikipedia