So, I've been working on this kernel for some years now, and I've decided I can do a release now, mostly because I'm about to abandon the project soon, because my goals have changed and I'm going to be undertaking a new project based on the seL4 capability-based microkernel, for various reasons. Zambesii has some really neat features, and it was just about ready for a version 0.01 release, when I had finished the Uniform Driver Interface implementation. This was not a toy project. Zambesii was developed and tested to work on Bochs, Qemu, VMWare Player, Virtual-Box, and Microsoft Virtual-PC, as well as multicore real hardware machines. I was very meticulous about ensuring that it worked in as many environments as I was able to personally test on. I don't recall its working status since I haven't touched it in some months, but it's not one of those "It works in Qemu only" type of "GDT + IDT + Hello World" projects.
The kernel is portable and scalable, with an (almost) fully asynchronous API. The only architecture it's ported to is IA-32, but it was written and designed to be portable, so porting it to other architectures shouldn't be difficult (and should be easy, and was intended to be easy). Something perhaps interesting is that it's written in C++. The build system supports G++ and CLang++, but the binary that's produced by CLang++ doesn't run though. It fails around the constructor calling sequence, which probably means I just had to get crt*.o working and then do some extra debugging and I would have had CLang++ support.
It's very much an Eleanore Semaphore type of project, because you won't be seeing any kind of flashy graphics, etc, here. I was very focused on getting the internals right.
A non-exhaustive list of the features is:
- Symmetric multiprocessing, tested on real hardware.
- Cache-coherent Non-Uniform Memory Access, tested in Qemu only, because I have no access to a ccNUMA machine to test it on. But Geist did allow me to test on a NUMA machine at his workplace.
- Demand paged kernel heap.
- CPU hotplug (untested, but the code is there).
- Memory hotplug (untested, but the support is there).
- Multiprocessing, and multithreading.
- Soft real-time priority-based scheduler.
- Native Uniform Driver Interface environment implementation.
- AP CPUs boot in parallel asynchronously. When I got this done, I remember being pretty proud of it.
- Other stuff I don't remember
The UDI environment implementation is pretty much on the brink of completion: I have UDI processes able to be spawned and executed according to the UDI specification, and a udiprops binary compiler and parser, and other neat stuff. The remaining work for my UDI implementation was for me to write the UDI service calls: right now a UDI driver will be initialized, and begin executing, and then be unable to make any service calls to the OS, so the next step was to implement the UDI syscalls, and that would have hopefully been the spark that would have got UDI going in the hobbyist community and broken the "Chicken and egg" problem. I plan to use UDI in my next project, though.
I may or may not complete the UDI implementation in this kernel and possibly port this kernel to ARM before moving on, but that remains to be seen. Feel free to comment, ask questions, like, subscribe, upvote, and share. https://github.com/latentPrion/zambesii