OSDev.org

Craze Frog wrote:Those of you who are writing a microkernel, are putting the scheduler inside or outside the kernel?

Outside, like almost any component.


JAL

I'm writing an OS using a kernel free design (i.e. no specific kernel). I was intending to use a nanokernel design, but ever since I switched to using SIPs (software isolated processes, like Singularity) I figured out how to split the responsibilities of the kernel into separate tasks. So now, I have a small collection of "core services" that provide task management, scheduling, memory management, optional paging, communication (through channels), interrupt management, and security.

I agree, microkernels are modern and monolithic kernels are becoming old now, but in all fairness, if a microkernel does somthing wrong, it can really screw everything up. Monolithic FTW

Craze Frog wrote:Those of you who are writing a microkernel, are putting the scheduler inside or outside the kernel?

Inside

FutureDomain wrote:I'm writing an OS using a kernel free design (i.e. no specific kernel). I was intending to use a nanokernel design, but ever since I switched to using SIPs (software isolated processes, like Singularity) I figured out how to split the responsibilities of the kernel into separate tasks. So now, I have a small collection of "core services" that provide task management, scheduling, memory management, optional paging, communication (through channels), interrupt management, and security.

Intersting idea, but to communicate, you must request some entity for the communication. And you must, by definition, communicate with that entity in a special way, to avoid a chicken and egg situation. I would call that entity the kernel. Also, you'd want only a limited number of processes in kernel space (as opposed to user space). Your 'core services' may run in kernel space, and thus I would consider them the kernel together.


JAL

I'm writing an OS using a kernel free design

Same here although I think mine will be similar to a hybrid kernel I'm not quite sure yet though.

jal wrote: Interesting idea, but to communicate, you must request some entity for the communication. And you must, by definition, communicate with that entity in a special way, to avoid a chicken and egg situation. I would call that entity the kernel. Also, you'd want only a limited number of processes in kernel space (as opposed to user space). Your 'core services' may run in kernel space, and thus I would consider them the kernel together.

I think you're not quite getting the SIP concept. In a SIP based architecture, all tasks run in kernel mode, but they're isolated from each other using software verification and type-safe code. They're all running in kernel mode according to the processor, but their code can't interfere with each other or they won't be loaded. In my kernel design, the core services are isolated from each other just like user tasks, but they are more privileged and can execute certain special instructions. As an example, device driver tasks would be running in their own tasks that are isolated from everyone else, but they would be given permission to read and write only to certain I/O ports that they needed to perform their job.

You're right in that there needs to be a system of communication between tasks, and that has traditionally been performed by the kernel. The chicken and egg syndrome comes in because of the hardware isolation that most operating systems use, but by using SIPs I can move IPC to a separate "Communication Manager" task that can be called by a normal task, but is still isolated from the rest of the operating system. I'm hoping that this system of least privilege in the kernel will help improve security (you can't just do anything if you take over one of the core services), stability (crashes and bugs are isolated) and make it a lot easier to write (a few separate services instead of one giant kernel).

I'm writing a paper on the design, and I'm wondering if anyone would be interested in me posting a link to it.

~~ FutureDomain ~~

FutureDomain wrote:The chicken and egg syndrome comes in because of the hardware isolation that most operating systems use, but by using SIPs I can move IPC to a separate "Communication Manager" task that can be called by a normal task, but is still isolated from the rest of the operating system.

I still see a chicken & egg problem here. Normally SIPs can only communicate via IPC. If the "Communication Manager" implements IPC, and other tasks use IPC by "calling" the "Communication Manager", then how do they in fact "call" it? Is that not also IPC? Do you have a special form of IPC just for getting to the IPC server? Seems a bit strange IMO... Even Singularity implements IPC directly in the kernel.

Colonel Kernel wrote: I still see a chicken & egg problem here. Normally SIPs can only communicate via IPC. If the "Communication Manager" implements IPC, and other tasks use IPC by "calling" the "Communication Manager", then how do they in fact "call" it? Is that not also IPC? Do you have a special form of IPC just for getting to the IPC server? Seems a bit strange IMO... Even Singularity implements IPC directly in the kernel.

I've thought about that for a while. My techniques usually use a special bytecode instruction that is JITed to a simple procedure call to the communication manager. I've toyed with the idea of a traditional "syscall" instruction, but I'm currently leaning towards separate "send" and "receive" bytecodes. Either way, it just jumps to the communication manager. IPC is one of the few things that must be shared between all tasks, yet cannot use other primitives. In fact, my original nanokernel idea was to just have a RPC system and interrupt handler in the kernel (plus a few calls for directly manipulating the hardware). But I think that a special bytecode instruction would be required to implement it on a kernel-free design.

~~ FutureDomain ~~