what is difference between kernel and driver?

Question

Since my primary language is C++, and is often praised for its hardware capabilities, I decided to get into computer architecture a little more. As I was looking through some stuff, I stumbled upon device drivers. So, naturally, I decided to look it up. From my understanding, the device driver is a computer program that handles specific hardware components. I also know that the kernel is a computer program that acts as a bridge from software to hardware. For some reason, my mind can't differentiate the two. When it comes to the windows platform, can somebody explain the difference to me and explain the different roles that they play. Thanks in advance.

Answer 1

These terms aren't extremely well defined. But here's some ramblings on the subject...

Note that when you install Windows (or Linux, MacOS or whatever), you are not just installing the basic OS - it would be rather boring (at least for anyone who isn't a very good programmer). You are also installing a User Interface, a Shell (command prompt), Web-browser, Print-spooler to send things to your printer, a bunch of "useful" service processes, and so on. These are "applications" that run on top of the OS, but they are an essential part of what most people call "the OS". The core "OS kernel" is a few megabytes, but a typical OS installation is tens of gigabytes.

The "kernel" of an OS is the very core, without which there is no OS - at the very least, it handles loading applications, switching between tasks, time-keeping and so on. To make a small OS for a specific piece of hardware, we can integrate the "device drivers" for the serial port and timers, for example, directly in the OS - the timer would perhaps be a dozen lines of code, and a simple serial driver would be 100-200 lines. But it will ONLY run on hardware that is 100% compatible with the hardware it was designed for. Change the meaning of one bit in a register, and it (may) stop working completely.

If we want our OS to run on something with a bit of variable hardware - a PC is a great example of how you can essentially change nearly every component in the system and still end up with a reasonably consistent experience. And now we either need to write code that works for both nVidia and AMD/ATI graphics (as well as Intel and a few others if we want to support ALL PC hardware), and there are dozens of different models of graphics hardware within those few brands. Network cards (or built in networking), Hard Disk Controllers, CD/DVD drives, USB controlers and USB devices, etc, etc.

Before we dig too deep, we need to explain "user mode" and "kernel mode" - these are "protection levels" in the hardware - user mode is what your application is running as when you write regular C or C++ applications for Windows (and Linux, QNX, Android, MacOS, iOS, etc). User mode provides safety [assuming OS works correctly] between different processes, and that your "wild pointer" doesn't accidentally cause your entire hard disk to be formatted, etc, etc.

Kernel mode allows "free access to everything", in the sense that if you really want to, there is nothing in the hardware that stops your code from changing the memory mapping and reading any memory in the machine. Or your network driver writing it's packet data directly onto the display, the hard disk driver writing it's data directly into the web-browsers history buffer, etc. Only good coding and strict adherence to customs and guidelines prevents this.

The driver will "register" itself with the kernel, saying that "I will deal with hardware of this kind [nVidia graphics cards, for example], so please tell me if you have any of that kind - or if it turns up later (hot plug devices)". This is done through a defined interface - which often varies depending on the type of hardware, so network drivers and hard disk controllers have different interfaces, and of course graphics cards behave differently to both of these.

There are actually, often, two levels of drivers - "kernel drivers" (in linux "kernel modules") and "services" that run in user-mode (so do not have access to all the hardware directly, but must use the OS kernel and the drivers to access the actual hardware [possibly with some "holes" provided by the OS / kernel driver that lets the user-mode side access the specific hardware that it needs to access]. This model is used to make the driver a little safer - so most of the work is done in user-mode [where the OS provides some safety against bad code reading/writing things that it doesn't actually should be accessing (e.g display driver writing to the hard disk caches)].

Drivers also help keep the core kernel simple - similar to how you write other code in modules and functions within modules - the "main" code doesn't have to know everything about what a particular module does.

Different OS's have different models for how much the OS itself knows about, and how much is separated out. At one extreme, you have "microkernels", which is essentially just a task manager, a little bit of time-keeping, and that's it. If you want to read files, you need to install a filesystem module that is it's own little "task", if you want to use networking, there is a "task" to install for that, etc. At the other end of the spectrum, you have "monolithic" kernels like Windows and Linux, where nearly everything is built into the kernel - at least to the point that the kernel has functions to open files, send packets to a network, etc - there are of course drivers to handle the actual interface to the hard disk controller and network controller, but the knowledge that files exists and can be opened, closed, read, written, etc is in the kernel.

Just like picking a political model to run a country, all of the models have people saying their favourite one is better than all others. The truth is probably not as extreme as that.