1

My understanding of dkms is that its a way to dynamically manage all connected/disconnected device drivers on a Linux system. If that's correct, then I have to imagine that it allows you to configure a "repo" where device drivers can get installed, so that as soon as a hotpluggable device is connected to it, it finds that device's driver (in this repo) and loads it.

If that's correct, then where is this repo and is that location configurable? Can it be configured to look for drivers in a remote location (using HTTP, TCP, etc.)?

Also, does dkms, offer a way to dynamically update/upgrade device drivers at runtime? It would be nice to push device driver updates to this repo and then have dkms automatically release/unload the driver, overwrite the old driver with the new/updated one, and then reload that new driver.

Zac
  • 309
  • I don't believe udev has much to do with device drivers. I believe it only manages device events and device names in some cases. Device drivers can be dynamically loaded with dkms, which is different from udev. I suggest you read man udev and man dkms. – jayhendren Jan 27 '15 at 17:39
  • Thanks @jayhendren (I'd upvote you if I had the rep to do so) - I appreciate the heads up, and I have modified the question to reflect your correction. – Zac Jan 27 '15 at 17:46

1 Answers1

1

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:

  1. The kernel invokes modprobe to load a driver.
  2. modprobe loads a module file from /lib/modules.
  3. Now that a driver is available, the kernel notifies udev that a new device is present.
  4. 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.