Kernel Model

[mr. xsism]

What kernel models do you prefer to use or dev? Why? What advantages are there? List what you think as advantages. Do not list disadvantages to others, only advantages to what you prefer.

Can anyone explain the model that they prefer? Especially cache since i haven't read up on it. ???

I prefer the nano since it is like a microkernel, but tends to be faster and more easilly developed.

Are there anymore models that I don't know of?

Regards,
mr. xsism ;D

[Mr_Spam]

The cache kernel is a type of exo-kernel (like nano-kernel is a type of micro-kernel) where the suproviser kernel cache's data about the current, or next process in memory to provide preemative multitasking. The rest of the kernel's functionality, memory management, scheduling, message passing ect, is found in either a single user-mode global memory mapped into the address space of all the processes or each process may have its own LibOS (like the typical exo-kernel)

In theory, this type of kernel should be extreemly fast since an application dosn't call an interrupt vector to comunicate with the kernel . The dissadvantages to this method is security and potentually stability maybe comprimised. An application can send arbitrary data to specific functions in the user-mode kernel, which can be potentually destructive to the entier system.

I am developing this type of kernel for the basic reason, only one documented one exists for the PC hence i would be writing the docs on this methodology. That kernel was created by stanford's computer science department. http://www-dsg.stanford.edu/papers/cach ... /main.html I can also create a sister micro-kernel just by taking the user-mode kernel and placing into the supreviser-mode kernel with not to much additional work. All the hardware and software drivers in my OS will have there own address spaces, to get the stability and modularity affect of a micro-kernel aswell.

[Mr_Spam]

[

[nullify]

I'm generally leaning towards a monolithic kernel approach, because you get a good mix of speed and protection, and its simplistic model eliminates any need for workarounds or ugly hacks to solve problems introduced in other models. This model has been around for a long time, so its time tested and proven to work well. The non-modularity of it can be addressed by using kernel modules like Linux does, or in fact I cannot forsee anything that would hinder you from developing traditional microkernel-like userland servers in kernel space. You could put a well defined communication interface between the core kernel and its modules and device drivers also, like AtheOS does. Although it is true that everything is in kernel space and they would not be protected from each other, this may not be as big of a problem as it seems, because system code should be as bug-free as possible anyway. Hmm, the model that I describe is starting to lose some of its qualities of a traditional monolithic kernel, maybe it should be called something else

P.S. Could someone describe the nanokernel approach, please? I've heard little about it.

[mr. xsism]

well, i went ahead and put in my vote: nanokernel. A nanokernel ia the smallest kernel possible of them all. It doesn't matter what langaueg it is written in, it just has limited capabilities. It relies a lot on plugins for its featurs all except system hardware handling like PIT and PIC.

For example, i have a nanocore project called HALfix. It has a core limit of 64KB and a set amount of responsibility.

readme.txt excerpt:

Code: Select all

-nanocore will only be able to do these things:
 1 setup GDT
 2 setup IDT
 3 remap PIC
 4 setup PIT
 5 setup tasking
 6 setup MM
 7 access floppy

You can have some more details from the readme.txt if you just douwnload the source. The current core size is 8.5KB with PIT,IDT,GDT,PIC,stdio,cpuid,exceptions,debug functions, a few lib functions, and string functions. MM is being implemented ATM.

A nanocore can take advantage of assembly for increased tightness in code and smallness of the binary image. I chose to use C for the kernel and use assembly where it would obviously increase speed.

That's my definition of a nanokernel. Although, nanokernel is more of a pseudo kernel. Here are some other "definitions":
http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html
http://c2.com/cgi/like?NanoKernel
http://www.ussg.iu.edu/hypermail/linux/kernel/0206.0/0294.html


Regards,
mr. xsism

[nullify]

xsism: Your description of a nanokernel bears quite some resemblance to a microkernel. In fact, the only difference that popped out at me was that the microkernel's servers/kits architecture was broken down into user space plugins. In your thread-starting post, you mentioned that nanokernels tend to be faster and easier to develop than microkernels. Is there some understanding that I'm missing about nanokernels? What makes them faster and easier to develop than microkernels?

[slacker]

where can i read about different types of kernels?

[mr. xsism]

slacker, one of the links i gave above has a lot of different kernel models.

nullify, it is faster because it is MUCH smaller than a microkernel and the plugins run as ring0 with kernel, but in different address spaces. It is easier to develop becasue you can seperate the differnt plugins and work on them independently. Plus, since the nanokernel has LIMITED responsibilities it is less complex than monolithic and some micro kernels.This kernel model is still developing a lot. Some of what I have said about nanokernels is my take of it mixed in with my ideas. Is there a more definitive definition of the nanokernel model? I don't know of one, therefore I am creating my own definition. The main characteristic of a nanokernel IMO is it's size/responsibilities. They are limited thus faster, simpler, and smaller.

Regards,
mr. xsism

[Solar]

I voted "micro", although my concept isn't a "clean" microkernel, but packs some more functionality into the kernel core for performance reasons (package handling, and some more things).

Then again, the kernel isn't monolithic either since the kernel image is constructed from multiple modules at boot time... (I like Multiboot / GRUB )

[anubis]

for me [glow=green,4, 12]Micro[/glow] is the in-thing.

I find it big enough to do major things like emulate the whole drivers and small enough that it can be easily followed by others reding the code.

With monos i had the experience of 'where i put that god-damn code' kind of syndrome :-[.

Once i finish a satisfactory part of my OS, i am thinking of trying Nanokerneling it....

[Tim]

You can achieve that just as well with a monolithic kernel. I have each device driver as a separate DLL, with only the core functions in the kernel.

The only difference between a micro and a monolithic kernel is that a microkernel will have each system service in a separate user-mode process, whereas a monolithic kernel will have them all in kernel mode.

[nullify]

oK, i'm a bit confused now. Originally I thought the nanokernel was like a microkernel (as mr. spam said), but xsism says the nanokernel's functionality is in ring 0, and Tim says when you have all the features in kernel mode, its monolithic. Does that mean the nanokernel can be thought of as a type of monolithic kernel?

[be]

But nanokernel does not have ALL features, there is only minimum. I think nano- or micro-kernels are good for embedded systems and other function specific stuff, so type of kernel should be determined by the goals of developer.

[mr. xsism]

ok,
like i said, my definition is probably somewhat twisted because I am defining it. I am NOT going by any OTHER set definition. I just looked at the name, nano. Nano means small, extremely. So i said to myself,"a nanokernel should be small, so i need to limit it's CORE functionality." Nano CORES are minimalist systems, not full of functionality like monolithic kernels. ALL monolithic kernels run the drivers inside their own code. For speed, i realised that microkernels are at a loss because they put each module in a different process. So i decided i would add the rule for nanokernels that they run system modules NOT part of the CORE in ring0 in ONE single user space. I haven't quite decided whether it will be in the kernel's mem space too, although i'm sure i'll add that to the rules.

I can say that the nanocore concept is MAINLY a derivitive of the microkernel concept model. But according to what tim has said, it also is similar to the monolithic model. No matter, there are two key points of the nanokernel: minimalist structure(limited size/responsibility) and singular modularity("plugins" run in same address space to increase speed, possibly beside the nonocore).

That's it. SMALL size and MODULAR. Nothing else to be said.

Regards,
mr. xsism

[be]

Why you flaming about name? It doesn't matter. Look at the QNX. They say that QNX is microkernel system, but it's kernel doesn't have even memory manager - it's external process (I'm talking about Neutrino). Better look at internals, than the words.
P.S. Microsoft says that Windows NT is microkernel system (!)