OSDev.org

What is the role of a kernel in your opinion?

There is a lot of bootloaders that are doing alot of things.. and as most projects here are microkernels, there are alot of drivers doing alot of things too.

So what things have you left in your kernel and why did you do it that way?

Mike

From a technical standpoint, I would consider the kernel any part of the operating system that persistently runs in the highest privilege level. This makes it fundamentally a processor driver: all processor features (interrupts, memory protection, multitasking) have to be handled in some way by the kernel (even if policy is exported,) because those features have to be limited to the highest privilege level.

In my kernel, which I personally consider a microkernel, the only things in the kernel pertain to interrupts, system calls, basic IPC, and multitasking (with threading), including memory manager and scheduler policy. All device drivers run as processes with port I/O privileges. Message queueing and verification, executable loading, and the VFS (which is distributed) are part of the C library.

Looks like u missed a lot of readings. Please check the Wiki.

What is in kernel, and what is in device-drivers have changed over time. Lately, the reason for this has to do with size limitations (kernel getting above 64k). What currently is in kernel is application / process management, scheduler, linear and physical memory management, GDT/LDT descriptor management, interrupts, handle management, paging, gate management (basically). I also have a driver called "util" that contains essential functions that used to be in kernel (IO, multiple-wait interface, environment, random number generator, CRC-calculation). The last time when the SMP scheduler overflowed kernel, I had trouble move more modules as they had too strong dependencies, so I instead removed macros from the scheduler and replaced them with procedures to save space. I suppose that the kernel set of functions left in kernel are things that are hard to separate.

In my design, both kernel and device-drivers runs in priviledged mode. There is no support for running device-drivers at ring 3. Protection and isolation is instead enforced with segmentation.

If you break it down to the smallest common denominator, the role of a kernel is to do those things that require supervisor / ring 0 privileges.

Depending on your design, that might be very little (microkernels), or very much (macrokernels). (Ignoring exokernels for the moment since they were only invented to complicate discussions like this one anyway. )

Thankyou for your replies

Yes, The general opinion seems to be the same which is good.

I will disagree a bit with the general opinion that kernel == privileged mode by providing a counterexample: Singularity. By default in Singularity, the kernel and all processes run in privileged mode, but software isolation is used to keep the processes from stomping each other or the kernel. There is still a system call API in Singularity, but by default no privilege level change is required to call it (you can run processes in ring 3, but this is configurable).

The key point is that the system call API is a trust boundary, regardless of how it's implemented. You could define the kernel more generally as the part of the OS that is fully trusted to manage processes and hardware resources. The granularity of resource management is really what gets you into the micro-verus-monolithic spectrum (from just interrupts and the MMU to all device drivers in the system).

Just bunch up Singularity with exokernels, git, and that very specific customer of ours that insists on having our software running on AIX: Things that complicate matters and are going on my nerves.

Colonel Kernel wrote:The key point is that the system call API is a trust boundary, regardless of how it's implemented. You could define the kernel more generally as the part of the OS that is fully trusted to manage processes and hardware resources. The granularity of resource management is really what gets you into the micro-verus-monolithic spectrum (from just interrupts and the MMU to all device drivers in the system).

I like it. Then I can define my system as a micro-kernel with two isolation barriers. The first one is the device-driver API, which all device-drivers are allowed to use, and the second one is the application API, which device-drivers and ring 3 applications are allowed to use.

I suppose I could even move device-drivers to ring 1 or 2 if I wanted to. The only reason not to do it would be complicating interrupts with ring-switches. Or a device-driver could alias its interrupt handler code to ring 0 for ISR handlers, and run the rest of the code at ring 1 or 2.

This probably just complicates issues more (obligatory ) but capability-based systems have a very different idea of trust. Every piece of the system is trusted with exactly what it needs (i.e. POLA to the max), so there are any number of barriers from the kernel to the device drivers and all the way out to any part of the system you like.

You could even imagine a processor that would make a kernel completely unnecessary- it would just hand off all the resources in the system to the equivalent of /bin/init, which would handle booting and then be rather unnecessary. IPC and such wouldn't need to be mediated by a central authority because init would have given out either address space handles or os-implemented process handles wherever they're needed.

That is the basic idea of an exokernel (discussed above), isn't it?

Capability-based systems use interfaces to resources that look like objects with a collection of supported operations. You can replace the implementation but implement the same interface (see Unix file handles as an example). Exokernels focus more on the permission part, and there's still a central, trusted kernel. They're a bit different from what I'm describing, but the actual implementation is probably the same.

Solar wrote:Just bunch up Singularity with exokernels, git, and that very specific customer of ours that insists on having our software running on AIX: Things that complicate matters and are going on my nerves.

I'm just making sure people remember the difference between concepts and implementation details. Hardware privilege level is an implementation detail. "Microkernel" is a concept. Defining one in terms of the other is a classic design mistake.