Blog

Binary releases are expected to start tonight or tomorrow, once the new build script works…

During the final replacement of legacy code a few things have been broken or fixes to existing problems have been delayed:

• Floating point support may be in a half-working state, it probably works but prints some TODOs when activated and has had no attention since before replacing the rest of the kernel
• Due to API breakages the utilities from xv6 no longer compile at all, this is kind of intentional as I didn’t want to preserve the old headers etc.
• A few bugs were found in the filesystem code, these have been partly fixed during the replacement of old system call code but some probably remain
• Threading is implemented but not yet finished, it mostly works but there will be some bugs if some filesystem operations are invoked from multithreaded programs
• Error handling is unfinished, so some recoverable errors may cause kernel panics instead of failing gracefully
• I simply haven’t had time to investigate some possible scheduler bugs when running under load

Addressing these problems will be delayed until after 1.0 or may not need addressing at all. The base system is functioning well and some command-line programs have been replaced already, once I have enough working to show some basic documentation about the software I’ll start uploading builds.

Proper testing including stress tests will be resumed later.

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.