OSDev.org

Kevin wrote:Certainly no proper microkernel has a disk or filesystem driver built in.

Being able to attach the label "microkernel" to something isn't a religious thing with me.

Kevin wrote:Certainly no proper microkernel has a disk or filesystem driver built in. Loading these drivers from the disk is the job of your bootloader, so that the kernel can take an in-memory image of the executable and create a process for them without having to access the disk by itself.

Multiboot supports this as so-called modules, so you'll be able to go this route with GRUB, syslinux, qemu -kernel, etc.

+1, i'm glad someone made it obvious. Load only what you need, teach the kernel through drivers and libraries, and have a kernel that knows how to learn.

VolTeK wrote:+1, i'm glad someone made it obvious. Load only what you need, teach the kernel through drivers and libraries, and have a kernel that knows how to learn.

I have got 16Gb of memory in my computer, so I am sure it can spare a few kilobytes for a few drivers which might not be needed all the time. We are not back in the days of MS-DOS with its 640kb, and I only talking about having three drivers permanently linked into the kernel..

mathematician wrote:Being able to attach the label "microkernel" to something isn't a religious thing with me.

That's fine, nobody forces you to write a microkernel. But by suggesting that you need a disk driver in the kernel, you indirectly claimed (even if unintentionally) that a microkernel isn't even possible. Which is obviously wrong.

mathematician wrote:I have got 16Gb of memory in my computer, so I am sure it can spare a few kilobytes for a few drivers which might not be needed all the time. We are not back in the days of MS-DOS with its 640kb, and I only talking about having three drivers permanently linked into the kernel..

You're aware that saving the memory for unused drivers generally isn't the motivation for having a microkernel? In the case of a modular monolithic kernel you may have a point that directly compiling in a few drivers isn't that bad.

However, I think three drivers is overly optimistic. There's not only one file system, and there are different types of disks, and if you want to support network boot, you quickly get many more drivers in.

I think at boot time, you detect the hardware which is required for example a Display Adapter and a
Storage Device, these are one of the devices that have to be initialized first, And these modules IMO
should be loaded by the bootloader. I think the FS Drivers shouldn't be inside the kernel binary as it
prevents the OS to support multiple FSes without recompiling the kernel.
After your Kernel is initialized and then you can easily load the drivers when they are required for example,
the network Driver should only be initialized when the user tries to use a networking feature.
Not only it increases speed at boot time but it also increases portability, if you want to only port you kernel to ARM or something similar, You will have less work as the Kernel only contains relevant stuff, After porting
the kernel you can port each module one by one, increasing efficiency and less code mess.

sid123 wrote: I think the FS Drivers shouldn't be inside the kernel binary as it
prevents the OS to support multiple FSes without recompiling the kernel.

We get it already.

mathematician wrote:I have got 16Gb of memory in my computer, so I am sure it can spare a few kilobytes for a few drivers which might not be needed all the time. We are not back in the days of MS-DOS with its 640kb, and I only talking about having three drivers permanently linked into the kernel..

3 isn't so bad, but surely you get the reason for my point though. It can become a problem. You have 16 GB of ram on your machine, but there are people who are still making due with 256MB somewhere.

Kevin wrote: You're aware that saving the memory for unused drivers generally isn't the motivation for having a microkernel? In the case of a modular monolithic kernel you may have a point that directly compiling in a few drivers isn't that bad.

However, I think three drivers is overly optimistic. There's not only one file system, and there are different types of disks, and if you want to support network boot, you quickly get many more drivers in.

As I said earlier, if the driver for the default file system (or hard disk) goes down, you can forget about reloading it because you would need the driver to load the driver. For all practical purposes the OS will have crashed (even with a microkernel).

sid123 wrote: FS Drivers shouldn't be inside the kernel binary as it prevents the OS to support multiple FSes without recompiling the kernel.

Once the kernel is in memory, you can use the resident drivers to load as many additional drivers as you like. As for porting the OS to the ARM, in the unlikely event of that community beating a path to my door, demanding to have my OS made available to them, the kernel would have to be recompiled anyway.

I don't see the problem here. There should be very few boot time drivers in order to provide the kernel or executive the interfaces necessary to load additional drivers and servers from, and only from, its boot disk and boot disk file system. The loader should be smart enough to determine what drivers to load based on user selection of their operating system (note that I am differentiating between a boot loader and manager here. The loader component should do the loading, not the manager.)

Regardless of kernel architecture, a bug within any boot time driver will result in a system failure. If it does not, then it should not be a boot time driver.

I would just like to point out something I read somewhere. Don't remember the source, though I believe it was some Minix literature. What I would like to point out is that a kernel may have uninitiated copies of critical drivers in memory. Once, say disk driver goes down, the kernel does not need to load a disk driver from disk. It has made an extra copy of the disk driver in memory at boot time. This way, the disk driver may go down without affecting the microkernel, while also, the kernel may restart the disk driver, without needing to load it from disk, which would be impossible due there being no disk driver.

Interestingly enough what you just described was a method that we were going to use; i.e. keeping a cached copy of boot time (critical) drivers. This would still indicate a bug in the driver or system software however would provide a method by means to restart critical drivers.

Putting drivers in userspace has value beyond just restarting failed drivers. There is no reason my disk driver should have the ability to read the password I use to log into a website. Any driver that executes at supervisor level without additional protection implicitly has this ability (it can read any memory).

Minimizing the kernel is about accurately expressing trust in the software system. Only one aspect of this is what software must be trusted to work for my system not to fail.

dschatz wrote:There is no reason my disk driver should have the ability to read the password I use to log into a website.

How about, performance reason?

While strict isolation provide decent protection, different OS might have different level of security by design.

Another workaround to make driver more difficult to peek into other application is address space randomization - this provide lower security level than strict isolation, but good enough for general user that, even malicious code want try to walk thru' the application's page table they do not have a fixed memory location to look for such interesting information(ie passwords), or insert hooks on keychain APIs. With a lot of work a malicious ring-0 driver may do whatever but that is generally not economic to justify such work.

On the other hand, some may decide that the driver should be trusted (by open source and have peer reviews) and just ignore that potential issue.

Yes, you're right. I mean there is no functional reason for that access. And absolutely a microkernel isn't the only way to acheive the same goals. My point is that just because a driver provides a critical function to the system doesn't mean it should be a part of the kernel, there are other reasons microkernels take the approach that they do.