Blog

My original plan was to focus on tools for developers while making some cool demos like an OS kernel. However I had to focus on finishing one part first and it ended up being the kernel.

The other tools are still workable and are valuable for use in the operating system but the SDK aspects are further behind than the kernel code, so I could possibly reverse the focus of the business a little into building a full operating system instead of treating that as an advanced test rig for my other (less complete) software infrastructure.

But this is early days so we’ll see, I’m still a tech infrastructure business whatever exact form that takes.

https://www.theregister.com/2025/12/17/dhruv64_india_homegrown_processor/

Just a (maybe new) shell program running on the kernel with a few commands. That will happen once I’ve finalised branding and done a little work on getting the “userland” back in a working state.

The system is fairly scalable with general-purpose design and should be especially good for robotics projects in the future, but it was mostly designed for testing & marketing my other software so the first release will mark it as being mostly ready for that. It’s not ready for many other real-world workloads yet but it should be some day soon!

It’s a bit of a blur but I don’t recall doing anything else between 7PM Tuesday and 7PM Wednesday except making coffees.

Bit of a headache. But it’s done.

The kernel rewrite I mean, not a whole release plan. Legacy code is now only used when booting on QEMU it can be omitted entirely when building for real hardware.

This should greatly help in the next stages of development as I won’t have to balance other goals with cleaning up old code. On the other hand it created more testing work for me as now just about anything could’ve been broken and for now it’s no longer compatible with the test suite.

So bringing up some userland programs is the next goal, I’ve already written a new init program.

The audit tool becomes a bit ineffective towards the end as I’ve mostly got headers & drivers left, so it’s showing 85% new code but the remaining ~14% “old” code will mostly be cut out into an optional driver package for running on QEMU.

I haven’t done a complete build without any old code yet but I’m fairly close to that stage, maybe a day or so more work. References to old headers have mostly been replaced but still remain in a few places, and some parts of the old drivers are still needed (most is only needed for testing on QEMU without SBI boot).

So the first version will only be “totally new” when running in the simplest configuration booting a demo shell from SBI, but very soon I should be able to start producing kernel builds that are only my own code!

Only about 500 lines of legacy example code to replace and I’ll have me an all new OS kernel, at least for simple builds. This is excluding a little clutter that needs to be cleaned up before release.

Some of the remaining “legacy” code may be spun into a new driver package covering QEMU functionality, and more work remains to be done getting demo programs packaged for use on the kernel.

Hopefully the next post will be about a successful build with no legacy code!

Fast Kernel Releases

My previous plan was to stage 1.x releases towards a fully new kernel design in 2.0 but it looks like the replacement code will be more-or-less finished any day now so for real releases I now mostly just have to worry about adding more features!

So it’s likely that a 1.0 kernel will be released with only basic features and some limited modularity. This kernel will be mostly stable but not fully tuned or perfected, so API/ABI stability will still be work in progress for the 1.x branch.

1.0 Will Be Limited

I’ll probably release a plain 1.0 version once the example code is fully or almost fully replaced. Although I’m inclined to call it something like 0.9 and finish drivers etc. it’s unlikely that I’ll find a better target for when to call it 1.0 than basing it on the replacement of legacy code.

This means graphics, advanced drivers etc. won’t be finished by 1.0 it will only be a “general purpose OS” in so far as implementing core features like multitasking. It won’t have full end-user features like a desktop and it won’t have an easy IDE for programmers yet, it will just be a tech preview running some programs on a new stack.

This probably won’t come with full public source code but there will be some code with the release, and this applies only to the kernel (the “userland” stuff is still just a demo).

The Rest Will Move Slower

I previously planned to tie other software versions to the kernel version but this may be unnecessary if the kernel is mostly finished.

Compiler backend & libc are already mostly working as well as some simple programs. These will probably initially be released in a simple demo package with the kernel but will eventually be versioned as well, particularly after the system becomes fully self-hosting.

The kernel audit tool is now reporting 81% new code and this number is even further ahead if only .c files are counted. Only around 1,500 lines of example code remains in .c files, with only a little more important stuff in headers & assembly files.

This means almost all code adapted from example code has been rewritten already which will make ~1.0 versioning simpler (previous plan was to do a release in stages as I finalised the rest of the kernel code).

More updates will follow as the final changes are made!

The writing of new kernel code is now back on schedule. After thinking I’d have to do a release in several stages I ended up replacing a lot of old code.

Kernel audit now reports 75% new code. Inspection of the remaining legacy code shows that the rest should be particularly easy to replace. More updates on this progress and final release plans will follow in the coming days.