OS kernel vs a proper OS

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
User avatar
mathematician
Member
Member
Posts: 437
Joined: Fri Dec 15, 2006 5:26 pm
Location: Church Stretton Uk

Re: OS kernel vs a proper OS

Post by mathematician »

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.
The continuous image of a connected set is connected.
User avatar
VolTeK
Member
Member
Posts: 815
Joined: Sat Nov 15, 2008 2:37 pm
Location: The Fire Nation

Re: OS kernel vs a proper OS

Post by VolTeK »

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.
User avatar
mathematician
Member
Member
Posts: 437
Joined: Fri Dec 15, 2006 5:26 pm
Location: Church Stretton Uk

Re: OS kernel vs a proper OS

Post by mathematician »

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..
The continuous image of a connected set is connected.
Kevin
Member
Member
Posts: 1071
Joined: Sun Feb 01, 2009 6:11 am
Location: Germany
Contact:

Re: OS kernel vs a proper OS

Post by Kevin »

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.
Developer of tyndur - community OS of Lowlevel (German)
User avatar
Bender
Member
Member
Posts: 449
Joined: Wed Aug 21, 2013 3:53 am
Libera.chat IRC: bender|
Location: Asia, Singapore

Re: OS kernel vs a proper OS

Post by Bender »

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.
"In a time of universal deceit - telling the truth is a revolutionary act." -- George Orwell
(R3X Runtime VM)(CHIP8 Interpreter OS)
User avatar
VolTeK
Member
Member
Posts: 815
Joined: Sat Nov 15, 2008 2:37 pm
Location: The Fire Nation

Re: OS kernel vs a proper OS

Post by VolTeK »

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.
User avatar
mathematician
Member
Member
Posts: 437
Joined: Fri Dec 15, 2006 5:26 pm
Location: Church Stretton Uk

Re: OS kernel vs a proper OS

Post by mathematician »

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.
The continuous image of a connected set is connected.
User avatar
neon
Member
Member
Posts: 1567
Joined: Sun Feb 18, 2007 7:28 pm
Contact:

Re: OS kernel vs a proper OS

Post by neon »

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.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
sandras
Member
Member
Posts: 146
Joined: Thu Nov 03, 2011 9:30 am

Re: OS kernel vs a proper OS

Post by sandras »

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.
User avatar
neon
Member
Member
Posts: 1567
Joined: Sun Feb 18, 2007 7:28 pm
Contact:

Re: OS kernel vs a proper OS

Post by neon »

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.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
dschatz
Member
Member
Posts: 61
Joined: Wed Nov 10, 2010 10:55 pm

Re: OS kernel vs a proper OS

Post by dschatz »

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.
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: OS kernel vs a proper OS

Post by bluemoon »

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.
dschatz
Member
Member
Posts: 61
Joined: Wed Nov 10, 2010 10:55 pm

Re: OS kernel vs a proper OS

Post by dschatz »

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.
Post Reply