The general plan for the OS is to create a micro-kernel based design with sufficient drivers that a basic user-mode interface can be created. The user-mode interface will include a basic tablet or laptop user interface with the ability to start user mode applications. The final goal is to develop a web-browser application to demonstrate the power of the OS.
FlingOS is an educational operating system designed to aid in teaching and learning low-level operating system programming.
Though not active in OS development, I am very interested in the design and implementation of OSes, given the time, could probably have a good stab at implementing something that vaguely works.
It is the nitty gritty details of bare metal OS development that fascinates me. Stuff like virtual memory mapping and task switching, the stuff primarily done by the core services, that have to be done close to the metal, that make C the ideal language. But higher levels, such as file systems and virtual memory management, and perhaps even some physical memory management, could easily be done using a higher level language using services provided by the lower levels. Even NetBSD now allows device drivers to be written in Lua, which I find amazing. I guess it points again to monolithic vs micro kernel design, but instead of using process boundaries to protect components, you can instead rely on language enforced boundaries to protect components from each other, and use the lower level code for the interface layer between components.
I wonder how much easier OS development would be if drivers could simply throw/catch exceptions instead of propagating errors up through call chains, with the inevitable errors that creep in that result in the error not being propagated or translated properly. Higher level languages have much better facilities in this respect and allow separation of error detection and error handling/recovery that straight return codes just don’t allow.
Hopefully, their Ahead of Time compiler work could eventually work work with or feed into the Mono AOT compiler.
That’s the bad thing about kernel development -as great of a feature as this would be, the impracticality of putting the required mechanisms in the kernel to support this makes it virtually impossible. This type of exception handling requires too much plumbing, takes up too much execution time, is too unstable, & relies on conditions that can’t be met inside of the kernel, currently. Even in kernels that’re written in C++, some features of the language just don’t currently work correctly inside of the kernel. Hopefully, someone will figure out how to make exceptions, rtti, & templates more palatable to kernel development.
I’ve written a pretty robust exception handling toolkit based on setjmp/longjmp for plain C. All I needed, beyond setjmp/longjmp was thread local data (for per-thread exception frames) and then some way of adding/invoking user provided destructors to make the code easier to make exception safe. Not much runtime required. The destructor facility even makes idioms such as RAII possible in an exception safe manner, as well as making memory management easier.
This would all be pretty lightweight to provide in kernel mode. There is no magic required to interpret exception tables, all destructor registration is done explicitly, and try blocks need only be high(ish) level so the setjmp overhead could be per-system call, not too onerous.
But I wouldn’t even dream of proposing such a facility to Linux, for example. I can imagine the flamewar that would ensue.
Templates in kernel mode are not an issue, as they just generate code at compilation time – similar to macros. RTTI, again not a big issue, as you just need to parse the type info of object, which is static structure. The biggest problem will be exception handling or any other language mechanism that requires you to allocate memory dynamically internally. There will be big problem if you try to throw exception inside of memory allocator
If you can throw exception in some places, but can’t throw exceptions in others, then it’s best to avoid exception handling altogether. Then there is issue with stack size used by C++ code and generation of unneeded instructions, so instead of using e.g. 4kB kernel stack (conveniently using page allocator), you will need 16kB for each thread if you create lots of temporary objects. This does not include space required by C++ runtime. What if you run of out space to allocate exceptions ? It would be silly to invoke out of memory kernel panic, because you can’t kill some process to free memory.
Edited 2016-01-05 01:56 UTC