0

I'm still new to understanding the Linux kernel so please forgive the basic question. If you could point me to resources that I could read/watch that would be greatly appreciated.

Coming from Windows, the hardware driver workflow appears to be that you install the core operating system first, then install drivers separately.

With Linux it appears that all the drivers are compiled into the kernel directly - does that mean an installed Linux distro comes with support for all supported hardware, even if you only use a subset of that?

Does that mean installing something like the proprietary NVIDIA driver (which is not included in the kernel) will actually require recompiling the kernel with the NVIDIA driver - where distros like Ubuntu and Fedora provide pre-compiled kernels with the driver built in?

I recently installed a driver on my Linux install that added support for the Xbox wireless dongle. It used "DKMS" to add the driver to my system without compiling it into the kernel.

Is DKMS a method to add micro-kernel features to Linux? Why aren't all drivers distributed as dynamic modules? Aren't kernel modules already dynamic as they are installed under /ib/modules?

How do dynamic kernel modules affect secure boot in the context of a self-signed Linux install?

muru
  • 72,889
David Alsh
  • 596
  • look at what the modprobe command does – jsotola Jul 30 '23 at 00:25
  • "Coming from Windows, [...] then install drivers separately", really, how often do you have to install drivers in Windows these days? There's a ton of things compiled in already. Unless it's some extension like LED lighting – muru Jul 30 '23 at 00:34
  • 1
    all the drivers are compiled into the kernel directly no, they are not - I have some (about a dozen) lite installs of Debian 12 (no desktop for example) ... and they have anywhere between 75 and 165 dynamically loaded drivers – Jaromanda X Jul 30 '23 at 00:42
  • 3
    I’m voting to close this question because it is based on a wrong claim. Modern Linux distros ship almost all drivers as modules. – Marcus Müller Jul 30 '23 at 00:46
  • Other than that, your question confuses a lot of concepts, which we would have to basically repeat Wikipedia to counter. Loadable modules and microkernels are two different things, you can have one with our without the other. Linux is not a microkernel. Dkms is easily researchably just a method of compiling code. Nvidia kernel shim modules never require you to rebuild the kennel. Seriously, there is just too many false claims for one question in here. We can't resolve all these misunderstandings in one answer. Please ask with more precise prior research and focus more sharply – Marcus Müller Jul 30 '23 at 00:50
  • I’m voting to close this question because it is based on false predicate – symcbean Jul 30 '23 at 01:14
  • Apologies for the naive assumptions, I'm trying to get a high level overview to help me focus my research. The kernel is a mystery to me. – David Alsh Jul 30 '23 at 03:01
  • Many questions here are based on wrong assumption, and it's ok - one of the purposes of answering those questions is to correct those assumptions (that other people can hold as well). Half of the questions here are scripts that don't work because of wrong assumptions and missing knowledge. That's the reason they ask those questions. – aviro Jul 30 '23 at 08:29

1 Answers1

3

I think you're conflating two related but different concepts: how drivers used by the kernel (statically compiled in, dynamically loaded), and how they're developed (in-tree, out-of-tree).

Drivers that are developed in-tree can be compiled into the kernel or loaded dynamically. Most are dynamically loaded. Drivers developed out of tree are almost always going to be dynamically loaded, simply because they're not going to be in the kernel source code of most distributions, so they can't be compiled in at all. If you have to install a driver separately, then it's developed out-of-kernel.

Drivers depend on a lot of internal APIs of the kernel, and as I understand it, Linux doesn't care about backwards compatibility of these APIs. The preference is for clean code, not maintaining a kludgy mess of ancient cruft and modern code for the sake of backwards compatibility (in a sense). So they prefer having drivers in-tree - if someone does some refactoring of an API, they are also expected to fix up any users of that API, and which they can do, since all users are in the same source code.

Of course, this can't be done for out-of-tree drivers. So they have to be compiled for a specific kernel version, as other versions may break the APIs they're depending on. For NVIDIA, and possibly others, the driver is basically a shim that wraps around a proprietary binary. (The shim supports multiple kernel versions.) This means that for distributions, you have to have a package of the driver for each packaged kernel version.

DKMS is a mechanism to help such out-of-tree kernels - instead of having a version of the driver packaged for each version of the kernel, DKMS will compile the driver for each installed kernel version.

muru
  • 72,889
  • Thank you for this! There are so many concepts to learn here and I've been struggling to find a high level overview to help me tie them together. – David Alsh Jul 30 '23 at 02:54
  • 1
    By contrast, do Windows drivers depend on kernel APIs that do not (or go through a process to) change rather than being maintained directly in the kernel source? – David Alsh Jul 30 '23 at 02:58
  • 1
    The way Windows is developed, they put a lot of attention to backwards compatibility, even adding code specific to some drivers or applications that depended on some unusual behaviour. – muru Jul 30 '23 at 06:21