Kernel Story

I have been fascinated about low level programming, operating systems and kernel development for a long time. During the years I have had multiple hobby OS and kernel projects. Most of them I have just forgotten since I encountered some issue I couldn’t solve, or there was major task I needed to do in order to continue, but really didn’t want to.

Now my current toy kernel is cxx-kernel. Originally it was called cxx-test-kernel, and my idea was to experiment if C++ would be suitable for writing kernel code. Of course I knew it would, but for me that was new. I had earlier written kernels with pure x86 assembly, and C. Thus I thought I could avoid some of the pitfalls with C++.

In that sense I was right, since this time I got many of the hard things done easier. Also previous experience helped a lot.

It has got forward a lot since the first version which just booted and said “Hello world”. Still it’s far away from being usable. If I would work more on the code, it would probably get forward faster as well. But this is not my work, this is still way to learn. Again, I’m doing this to learn and have fun.

That might be reason why there has always been long gaps in the development. I originally started this project in 2011, and worked a lot during the first years. Then again there was even years I didn’t touch it. This way I have got forward, touching it randomly and doing some small changes.

Graphics problems

I wanted to test again how it looks, and I noticed graphics didn’t work. For some reason VBE (VESA BIOS Extensions) initialization failed. I know the code has worked at some point, so either some other change has broken it, or then qemu has got forward and is incompatible with my way to handle it.

I tried quickly fix it without success. But that triggered and idea: what if I try to deprecate that? VBE is a hack. On Intel CPU:s it means one need to emulate virtual x86 mode. That means, one need to run virtual x86 (16 bit) CPU instructions in order to call BIOS functions. For that I originally ported and adapted x86emu from FreeBSD, and it made the trick.

This trick doesn’t work with 64-bit code and mode. Thus I started to investigate if there would be a way to deprecate that. VBE 3.0 apparently allows alternative way to control everything, and it looks promising. However I didn’t find good source to help with that.

I crossed upon Bochs VBE Extensions and decided to try. My first option was purely memory mapped operations, but I must have done something wrong since didn’t get it working. Thus I tried the I/O mapped way, and for my surprise I managed to set graphics mode and choose the resolution.

After few iterations and bug fixes I managed to get the graphics. That was quite fun thing to do, and the reason why I started this project. To learn something new, try things, and get the great feeling to make it work.

The old not pushed changes

Same time I noticed there was changes I haven’t pushed to Github. That was interesting since I had been working on SMP (Symmetric multiprocessing) and some other things. One reason might be that it was buggy.

During my graphics adaptations I checked my mutex implementation and noticed it was badly flawed. I just wonder how it could work in first place? I think it was just the happy path, and all other has been broken for a long time. This time I decided not to do everything myself, but to use the compiler built-ins since they’re perfectly valid. I think this is quite big improvement.

Feature list

For now the kernel supports many features, but still lot of things are upcoming. It support x86 (32 bit), ARM (32 bit) and Linux user space (just just as an app you can run on desktop). I never have started 64 bit support for x86, but that would certainly be something to do.

sSome features the kernel supports at the time given:

• Paging and memory management
• PCI
• ATA disks
• Primitive filesystem
• Multitasking
• SMP
• Framebuffer graphics
• HW random numbers (x86)
• Mutexes
• Atomics

Thus it’s pretty basic kernel for bit older systems, and fanciest and newest might have issues with it. For now apps can be run only in kernel mode, making this mainly unikernel or library operating system. I haven’t decided yet, where it goes, but most probably only time will tell.

That said, I have ported musl libc to the kernel. Thus most of the apps can be compiled and run on it. However that’s not fully true. One big thing is lot of missing system calls. There’s only few ones implemented, but idea is to expand the functionality there. I’m also trying to keep system call API compatible with Linux.

One of my plans is to make Python running on it. It might take a long time, but still that could be something great. For now it’s getting forward but because the missing functionality, I end up having errors, which means I need to implement again something new, which is not that fun since I have to.

In that sense I have no hurries, as long as I can run the kernel. Thus all virtual machines and emulators - like qemu - are very valuable. I have no fantasies of this being a “thing”. I would not mind if it goes somewhere, but I’m realistic. Still I enjoy working on it, and spending time on various stupid things…