OSDev.org

Personally i've decided to write a microkernel based on 3 main reasons (besides the already well-known advantages):

1. Microkernel design is largely unexplored, at least when compared to monolithic. More room for research.
2. The microkernel's main disadvantage is more processing power is required, but nowadays there is often ample power available.
3. There is no possible way i can compete with pre-existing monolithic kernels, especially as i'm developing solo.

Please don't start a flame war. This is just meant to see what your personal views on the possible designs are.

I'm writing a microkernel but with the VFS in the kernel to try and alleviate some overhead. It's only the virtual part in the kernel, all the drivers are in userspace.



Actually the main disadvantage is all the context switches, during which the main pipeline of the CPU (ALU, instruction decoders etc) are inactive, and said pipeline is flushed completely. Which causes efficiency problems.



Good thing you mentioned this!

I'm going for modular monolithic, but have not finalised quite how the drivers interact with the kernel yet. There will certainly be a level of dynamic linking involved as you would expect for a monolithic kernel but I have yet to look at whether going down the hybrid route fits in with everything else I want to achieve, so there may be support for userland drivers too.

Certainly the VFS, graphics and disk access will be done from kernel-space.

Cheers,
Adam

I think that a combination of both approaches is the best way to go.

So am I. Mostly for performance and I can also include select modules in the kernel (e.g. a floppy, DMA, and FAT12 controller!) My modules are event based, which means they sit in memory and do nothing until requested. I'm thinking about having the kernel ping each module that is doing heavy processing every few seconds to make sure it hasn't crashed, and if the module doesn't respond, then it is automatically destroyed and reloaded.

I plan on putting the vfs in user space at first. This should allow development thereof to be easier as i can first do some other stuff. Also i just don't feel like doing the vfs yet. Then in a later version i plan on moving it into the kernel for performance issues. Everything else i want to put in user space.

My kernel has/will have a scheduler, memory manager and ipc. Later the vfs too.

I started OSdev writing a microkernel... then after third redesign I decided it's sensible to move more stuff to the kernel.. and essentially started writing a monolith. Now that my monolith is getting to the point of actually doing something, I'm considering pieces to be moved outside again.

The result will probably be some sort of a hybrid. We'll see.

I like microkernels for their possible cleanliness. Monolithic gets messy very quickly. The overhead is of no importance to me, as I'm not making an OS to actually be used (chance of succeeding: 0%) by anyone but myself for research purposes, I like to try out new concepts in the design, rather than improve speed. An example: in our current design, we have even the memory manager in user space, the apps requesting memory by sending a message to the MM, via the kernel, that must map the message into the address space of the MM by sending a message to... the MM. Indeed very inefficient, with loads of overhead, but I like it :).

EDIT: As for the VFS, we have none as such. Our native FS is database oriented (like WinFS, but not on top of another FS), 'foreign' FSes like ext2 and NTFS are mapped to that.


JAL

My experience suggests kinda otherwise. The core is highly interdependant in both cases, which can be seen as complexity, but in a monolith you can build clean modules on top of that that do one part of the system. In a microkernel you build a fully-generic-handle-everything-and-kitchen-sinks-IPC system, which not only tends to get pretty damn complex, but what's worse, tends to make userspace servers complex as well.

I don't see why building clean modules on top of a microkernel wouldn't be possible, especially when defining interfaces and having the IPC call on those interfaces. Not much difference with having APIs that are called directly by the kernel. However, I must admit the OS I'm working on is in its infant stages, so maybe I'll experience otherwise when actually developing those modules further than the definition phase.


JAL

Is this the entire FS system, or just the VFS part and have the actual FS drivers (ext2, fat, whatever) in userspace?

Before I switched my OS to a monolithic kernel I planned to do the latter, but to be honest I got lazy and switched to monolithic, because back then I didn't know much about microkernel design and the current IPC system was a hack. Although I may switch back to a microkernel at some point in the future, who knows?

Just the VFS. The VFS has nodes that contain information about the server that handles those nodes (ext2 server etc). Actually more specifically it contains a pointer to a resource that could be "remote", i.e. in a different address space. The VFS can pass a call to that resource and intrinsically an IPC call is made if needed.

Intellectual purity gets in the way of writing pretty code, so I'm going for a hybrid right from the start -- no purity for me.

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

Inside. Mine is more along the hybrid lines.