Blog

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.

A uname command & system call has been added together with an empty man command.

Additional userland programs are being ported now based on some early successes. This should allow replacing of most of the old userland programs with more portable versions that can also be tested on Linux or elsewhere.

RISC-V at it’s heart is a very simple core standard for new general-purpose processors, making it very simple in theory, but CPUs usually need some extensions for real world use cases. So as well as the core standards the RISC-V organisation also promotes some profiles allowing people to select CPUs with some reasonable compatibility expectations.

Most boards I’m developing on are designed to match the (older) RVA22 profile with (newer) RVA23 being very similar but adding more extensions, which hardware manufacturers are only just now starting to finalise implementations of. So testing my platform with RVA23 will begin some time after those devices become available, with the UR-DP1000 possibly being one of the last major CPU release before everyone standardises on RVA23 (it should already have some of the RVA23 features but not all). The hypervisor/virtualisation extensions which are very rare on current devices should be standard as of RVA23.

Thanks to very heavy standardisation process between the RISC-V organisation and manufacturers, any software designed for RVA22 devices should be almost seamlessly compatible with RVA23 devices (aside from different peripherals on different devices), while for embedded developers some of those RVA22/RVA23 features will be overkill for many products (and my software should work without most of them).

So my current strategy is to support these new features where I can – especially I plan to look into any features relevant for HPC & server use cases – but my software will remain targeted towards cheaper/older CPU models and dev boards. Focusing on new models can also lead to problems like features just not working as expected or not being clearly documented, and earlier versions pre-RVA23 will probably still be much cheaper and more accessible for developers living in tight economic situations, so rest assured I’m very aware of these challenges and will be targeting my software at the most accessible and reliable dev boards. But I will always have both eyes on what’s ahead!

Other CPU Families

Thanks to C and my other development tools being very portable it should be relatively easy to port my whole stack to other CPUs as well, and some legacy AMD64/x86-64 support still exists in the C compiler (mostly based on the LICE code generator from before I extended it with my new backend). I also have a bit of other legacy code from my old OS projects that I could probably draw on for legacy CPU support (and xv6 also provides a version for legacy PCs).

So supporting architectures other than current RISC-V hardware won’t be a priority for my business in the short term but in the longer term support for other CPU families can be added, either by myself or by third-party/open-source distributors.

I’m very aware that most developers in Egypt, West Africa and other parts of the world don’t have such easy access to the latest Chinese & American tech as we do around Australia, so although the local government often choose to forego those advantages by not promoting innovation on new platforms I’m hoping to maximise those advantages by pre-ordering what I can when I can.

The Milk-V Titan should be quite a beast compared to earlier boards, with beefed up performance that will help drive all aspects of my software development, but the real feature I’m looking out for (and which there has been a bit of speculation about whether it will ship) is the virtualisation extensions. So at time of writing it looks like they are shipping with the virtualisation features fully working, and that should be a bit of a game changer for OS developers as it means we should have a fully stable stack where VMs will work quickly & reliably. On the other hand some features like this might still be a bit experimental so I’m trying not to rely on it.

My main development machine at the moment (not the main test board) is a top-specced Milk-V Jupiter and it’s running great so I’m very confident with that manufacturer and I’ve been watching for this new board since getting ahold of the Jupiter model. SpacemiT & Ky chips have been giving me pretty flawless performance so far (though a little slow for Firefox) so I’m sure I’ll be impressed by anything a bit faster than that – although the SpacemiT range is what I’d recommend for current projects and will probably remain a main target.

Some information about the UltraRISC UR-DP1000 chip and the Milk-V Titan board can be found here:

https://ultrarisc.github.io/ultrarisc-devblog/2025/06/18/dp1000-spec/

https://milkv.io/titan

(UPDATE) It looks like someone working on Linux has already found a hardware bug in this range of chips:

https://lwn.net/Articles/1042232/

Kernel Versions 1.x.x

As legacy code still used by the kernel provides many basic features already it will probably be pointless to call versions still using old/third-party code 0.x.x so instead they will be numbered starting around 1.7.x or 1.8.x reflecting progress towards a fully-new “2.0” kernel product planned for some time in 2026.

The 1.x.x releases will therefore partly be focused on establishing stable APIs for 2.0 including for programs to check what OS version they’re running on, and also on dampening any expectations for a perfect complete OS arriving at the first major release.

The versions will probably be marked internally as something like “SLOS 1.7.0”, the uname formatting will be finalised shortly. The main system APIs/ABIs should stabilise towards the end of the 1.x.x series (so 1.9.x should work mostly like a stable 2.0 version, but may break some compatibility with 1.7.x & 1.8.x versions).

Compiler Versions ~0.9.x

The compilers are close to usable for everyday stuff but will have more bugs in practice than the kernel code. So they are already usable but won’t really be “finished” until there’s a whole ecosystem for testing & deploying them.

If I get lazy these versions will be tied the OS version but maybe minus 1.0, so OS version 1.8.0 may match compilers versioned 0.8.0, and after 2.0/1.0 releases then things will be versioned in a more fine-grained way based on individual product features.

Other Tools Probably Tied To Kernel Version

For now the other tools like the package manager/archiving program will probably just be tied to the kernel version, so version 1.8.0 of the kernel will come with version 1.8.0 of the package manager and some “version 1.8.0” installations or packages of other tools, even if they aren’t necessarily updated for each kernel version.

This is just a practical consideration as obviously I don’t have a full team to offload managing new versions of each component to!

Kernel 2.x, Compilers 1.x

After a few proper early releases then the versioning will start to change to reflect individual updates & stability of each product. So for example the OS as a whole might eventually just have 2026 & 2027 versions while the package manager or other individual components might stay at something like version 2.1 for a while.

The programming tools will probably have simple versioning schemes easy for programmers (so probably not bumping major versions up every year, and maybe incorporating some rule like “1.2 is a stability release, 1.3 is a feature release, 1.4 is a stability release, 1.5 is a feature release”).

But that’s a matter for later, for now I will probably just tie most versioning to progress towards the “2.0” kernel rewrite.

Filesystem & Protocol Versions

The filesystem code already has an established versioning system and any other new protocols or formats will probably have individual versions too, these will be documented separately to software release versions and won’t match them 1:1.

Although the new filesystem format version is also “version 2”, the filesystem code supports multiple format versions and has it’s own options for setting or displaying the format version in use.

Platform-First Planning

The main goal is to develop a usable general-purpose operating system platform, not to finish one individual component to perfection or to achieve complete technological self-sufficiency. However, being very interdependent, the OS “release versions” should coincide with some individual components becoming more stable.

Necessary & Nice Features

For an okay-ish release version it will be necessary to finish some things:

• More documentation (especially of bugs/limitations)
• Reasonably stable kernel
• Reliable demos
• Some useful drivers/modules
• Build system improvements for “release builds”
• Downloads & backups for each release

For a perfect release version it would be nice to have:

• Fully new kernel code
• Bug-free C compiler
• Fully self-hosting codebase edit/compile/test
• Extensive manual pages
• Usable graphics/networking support
• Full packaging & versioning of each component
• Lots of new kernel features like dynamic modules

A Modest 1.x Release Plan

The “necessary” features can be thrown together very easily in a limited form if need be but working towards “nice” features should dictate the actual targets for a meaningful “point zero” release.

So I’ll revise my planning a little as I do further tests but I’ll probably drop a “first full release” version once I’ve finished off some more “nice” features.

A Possible Trick

As most of the code doesn’t currently have a versioning scheme but is already in a mostly working state, one trick I might use is to just bump up the kernel version automatically to 1.x.x based on the xx% replacement of legacy code and base the platform version on that.

This would make the initial releases smooth 1.x.x values starting around 1.7.0 or 1.8.0 while avoiding any possibility of perpetual “0.9.9 final beta 10 almost finished” type releases, while an eventual 2.0 release down the track would be the “fully new kernel code & stable API” release.

On the other hand if these milestones approach too quickly it would be pointless to call a final version 2.0 I might as well just do 0.8, 0.9, 1.0. So I’ll see how I go with some upcoming features and work from there!