Neither udev nor DKMS can be adequately described as “a way to dynamically manage all connected/disconnected device drivers on a Linux system”. Udev dynamically manages devices, not drivers — it creates entries in /dev
when a device is plugged in. DKMS is about drivers, but it has nothing to do with locating a driver for a device: it's a way to compile third-party drivers from source when installing a kernel.
When the kernel detects a device for which no driver is present, it calls the program modprobe
to attempt to load a module that provides this driver. The modprobe
program in turn consults a database created by depmod
which traverses module files (*.ko
) located under /lib/modules/VERSION/
. See debian does not detect serial PCI card after reboot for a more detailed description of this mechanism.
A nominal sequence of events when a device is connected and no driver is present in memory is:
- The kernel invokes
modprobe
to load a driver.
modprobe
loads a module file from /lib/modules
.
- Now that a driver is available, the kernel notifies udev that a new device is present.
- udev creates an entry under
/dev
for the new device.
There is no standard mechanism to download a device driver from somewhere when an unknown device is detected. The normal way to install drivers is to have all possible drivers installed on your system, provided by your distribution — it isn't always possible to download drivers (e.g. when you need the driver to connect to the network, or you don't have a network connection). Upgrading drivers works the same way as upgrading anything else, by upgrading the package that contains the driver file (which is often the kernel package).
DKMS intervenes when a driver is not part of the Linux kernel. It is hard to make a module binary that works across kernel versions and compilation options. DKMS is a framework to automatically compile modules for the installed kernel(s); the modules are distributed as source code.
man udev
andman dkms
. – jayhendren Jan 27 '15 at 17:39