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 udevandman dkms. – jayhendren Jan 27 '15 at 17:39