Are device drivers part of a OS kernel, or outside the kernel, or some are part of the kernel and others are outside the kernel?

If the third is correct, what devices' drivers are usually part of the kernel, and what are outside the kernel?

If the OS needs to be specific, I am interested in knowing about Linux (Ubuntu) and Windows 7.



In Windows, all drivers are in separate files, distinct from the kernel.

In Linux, drivers are one type of module. You can have all device drivers as modules, some built into the kernel and some left as modules, or all built into the kernel. You can create a Linux kernel that has module loading disabled, and in that case all hardware it is expected to work with must be included as part of the kernel.

For Linux, you need devices that need to be accessible during boot to be built into the kernel. This includes disk controller drivers, network drivers (for network boot), serial port or VGA console drivers (to display diagnostic messages), and bus drivers for intermediary hardware necessary for the CPU to access these devices (i.e. USB controller, PCIe, IDE, and/or possibly chipset drivers).

I'm sure it's possible for Windows to include drivers as part of the kernel. It might be done in some embedded or customized versions of Windows, but not standard PC Windows as far as I know. I actually think a couple of very elementary drivers are technically within the kernel (like VgaSave and Beep), but I could be wrong.

Windows can mark some drivers as "Boot Time" drivers., which would generally be the same category as the drivers identified above. If you access Safe Mode, you'll see the names of a bunch of drivers scroll by, these are all the boot time drivers.

  • 1
    A few notes, mostly Windows: 0) Drivers generally run in kernel mode (x86 ring 0), but Windows has "User mode driver framework" for ring-3 drivers. 1) Beep is external in Beep.sys. 2) You can include additional drivers in the installation media, but not as part of the kernel (NTOSKRNL). The same applies to all Windows releases, Embedded or not. – grawity Jun 3 '11 at 19:19
  • 1
    Further to grawity: Windows NT has no need for drivers to be part of the kernel. Its loader program takes care of the chicken-and-egg problem with boot start class drivers that other systems deal with by combining drivers with the kernel. (This is the case for many if not most protected mode PC operating systems, nowadays, in fact.) – JdeBP Jun 5 '11 at 14:58
  • @JdeBP: But how does it load, for example, %SystemRoot%\system32\drivers\ntfs.sys? (IIRC, the boot loader has NTFS support built-in in order to load the kernel, but I don't know about what the kernel does.) // Most Linux systems use an "initrd" archive to load drivers required for booting; would that be the same as Windows "boot start class drivers"? – grawity Jun 5 '11 at 15:13
  • 1
    You've answered your first question in the parenthetical sentence. Your second question is a proper question in its own right, to which the short answer is "No.", and which really is too long to deal with in a comment. – JdeBP Jun 5 '11 at 15:40
  • 1
    ... except that the process hasn't worked even approximately that way since Windows NT version 5 (Windows NT 6 working quite differently), the process doesn't work at all like that for ARC and EFI, and filesystem recognizers complicate the FSD loading mechanism. As I said, this is too long for comments. Make a question. – JdeBP Jun 5 '11 at 19:28

There are two ways to interpret 'part of the kernel'.

The kernel starts off (on boot) as a file on disk. If you're asking about on disk, they are not part of the kernel, but separate files. Almost all systems now have them as separate files. In really old UNIX days, adding a driver meant adding .o files to the kernel .o files and relinking a kernel.

If you meant 'part of the kernel running image' that depends. Windows can do both. In fact the display driver was moved from being not part of the kernel to being part of the kernel running image some time ago (from nt 3.51 to NT4.0) for performance reasons.

There are two general schools of OS design:

One is called a macrokernel. All OS stuff is handled in a single kernel running image. Linux and most unixes run this way. The advantage is it's fast, all parts of the kernel can read other parts of the kernel and communicate using memory reads and writes. The downside is that this gets messy after a while, and now you need to coordinate usage. If you can do something on purpose, sometimes you can do it on accident. There are no protections, and you may get a kernel panic.

The other is called a microkernel (which Windows NT started out to be, and Windows still sort of is). The theory is that the kernel doesn't do work, but farms out work to special code, but code not running in the kernel memory space. This other code cant touch kernel memory, or anyone else's. The upside, isolation from faults - bad non kernel code can't ruin the kernel. The downside - going back and forth to kernel mode slows things down. This is why the display driver was moved into the kernel in NT 4.0, the slowness.

These are generalizations of course, I haven't followed Windows microkernel design in a while, though I can be relatively sure of Linux design.

MacOSX is actually interesting technically, using a hybrid microkernel/macro-UNIX-kernel design. It used to support old OS9 binaries too - farming out to non-kernel space things that were kernel calls in MacOS9.

DragonFly BSD is an interesting offshoot of FreeBSD that's still a macrokernel, but uses message passing as a kind of poor mans isolation, and makes kernel work easier as a result.

  • Thanks! I was wondering if "macrokernel" and Monolithic kernel (en.wikipedia.org/wiki/Monolithic_kernel) are the same concept? – Tim Jun 4 '11 at 2:51
  • @Tim, @Rich: "Macrokernel" does not mean "monolithic" – instead it appears to be another term for hybrid kernel. Windows NT is classified as "hybrid". – grawity Jun 4 '11 at 8:52
  • Also worth mentioning is GNU Hurd (Mach microkernel with almost everything in user space). – grawity Jun 4 '11 at 8:55
  • 1
    The confusion in this answer stems from grawity's other point made in another comment. There's a difference between "executing in kernel mode" and "being part of the kernel program image". The Win32 graphics subsystem runs in kernel mode from Windows NT version 4 to version 5 (version 6 changed things again), but it isn't part of the kernel program image. – JdeBP Jun 5 '11 at 15:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.