OSDev.org

Hullo. I'm looking for some knowledgeable individuals who may wish to help me design a kernel architecture. I'm designing a kernel for my operating system and have put a lot of thought into it so far. I've already built some versions of the kernel but am not satisfied with the overall design.With that in mind, I hope to implement a well-designed kernel. The kernel itself is somewhat of a mix between a UNIX like kernel and an NT kernel. The file system design and process/threading design have been rewritten. So far the rewritten design is absolutely minimal and incomplete. This is why I'm looking for some additional help in the design. Any help is appreciated.

Please note that for exceptional help in the design I'm willing to float a few dollars (USD) to those who contribute the best design. Probably about $50-$100 depending on how good and extensive the design is.

EDIT: I apologize, I forgot to list the general goals of the kernel.

• Minimal kernel, with a good standard. A microkernel with necessary support for "kernel mode drivers." (I actually prefer the term "Kernel Extension" in this case.)
• Although the kernel is minimal, it's only minimal to a certain degree. Certain things should be controlled by the kernel like process scheduling, interrupt handling, and other relevant portions. I'm on the fence about putting the VFS handler in the kernel, but feel it's probably necessary for a standard design.
• Object-Oriented objects. (That's not to say the kernel is to be made in C++, on the contrary. It's written in C. However, I don't see any reason not to support a COM like interface where C++ support may be available through pure virtual functions. The idea is to follow a standard programming model across all application sources. Regardless of how it's handled, function pointers should exist in the objects and these objects should not be (in theory) able to crash the system, through their own use.
• Should be able to be easily ported across multiple architectures; a hardware abstraction layer is important.
• The general goal of the OS is to be able to function as both a game console OS and as a normal desktop OS. But more particularly as a hybrid of both. The process scheduler has been designed specifically to meet these needs.
• Writing drivers should make sense and support future expansion. Hence an OO model for objects.
• The general model of the OS is that the user is doing one active task at a time and may have several background tasks. This compares to say, a smart phone such as the Android. Where as I can only see one thing at once and there aren't multiple windows visible, but background tasks exist.
• In short, be secure, stable, efficient, flexible, and able to handle more demanding tasks by default.

Thanks in advance.

Cheers,
-naota

You are describing a highly monolithic kernel there, not a microkernel.

My apologies. I was under the impression that a microkernel was a kernel design in which most drivers run in user mode with the other apps, perhaps having a small design implementing only what is necessary.

I suppose the design is monolithic in nature.

AaronMiller wrote:My apologies. I was under the impression that a microkernel was a kernel design in which most drivers run in user mode with the other apps, perhaps having a small design implementing only what is necessary.

I suppose the design is monolithic in nature.

I'd say it's somewhere in between, with microkernel-style drivers but still with a lot of stuff in kernel mode. So you should gain a lot of the stability of microkernels (in the sense that external drivers are less likely to bring the whole system down*) but still have a fairly monolithic style.

* - this only applies if you force all DMA transfers to go through regular kernel functions, which check the physical addresses. That or use an IOMMU, but they're relatively new to x86 (although they have been around in general for a long time, I think)

The intent is that the kernel perhaps "knows" what things are, has modules for itself that run in kernel mode. (These would be important modules that most be run in kernel mode.) While other common drivers that don't necessarilly require to be run in kernel mode get run in user mode, with the rest of the apps.

I'm looking for someone who is willing to help me with this sort of a design to expand more on the specifics. For example, a strict definition of what a "driver" is or does in the OS and how it should be implemented specifically. How the kernel should be implemented to best fit this design, et cetera.

EDIT: An example of something the kernel knows about would be how the file system is structured, how objects work, how devices are accessed, and the design of the system overall. The kernel is meant to be, essentially, flexible within the design of itself. If other OS distributions were to arise from my own OS, nothing should have to be ported but the GUI code and stuff for random features the kernel generally has no concept of. At the same time, modules could exist to provide different implementations of certain modules. A vfs server module could exist as a driver to the VFS of the kernel, for example.

Cheers,
-naota

This is an in depth topic that has been discussed many times. Your goals are really general (it must multitask, it must have drivers, etc). Is it designed to be single or multi-user? Do you want a single executable to run on many architectures? What sort of IPC do you want (shared memory, pipes, messaging)?

In a microkernel the kernel architecture is only a small subsection of the operating system's architecture. A microkernel just provides a platform for processes/threads to run on and communicate with each other, typically this includes scheduling threads, IPC, mapping IO ports, handling interrupts/signals, and providing a way to load/unload processes.

Everything such as your driver interface can be outside of the kernel, and it's not difficult to do so and it keeps the two components seperated (one purely for managing processes, one purely for managing drivers).

I have the kernel now designed, this thread can be ignored.