Blog

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!

Kernel Audit Milestone

Kernel audit tool now reports 67% new code meaning now less than 1/3 of the kernel is still based on legacy code.

This milestone coincides with most of the system call API now having been rewritten (but still heavily depending on some old and partly updated functions internally).

System Calls Need More Fixes

The current API still mostly replicates the old one with a few changes only where necessary, this makes testing across updates a little easier for now.

Future versions will improve details such as using 64-bit sizes/offsets/indices where applicable. Proper system call documentation will follow as I start to prepare a final “1.0” API.

Coming Up

• Build system improvements especially for dealing with different hardware configurations
• Scheduler & threading improvements
• Further work on container support & maybe some prep for hardware virtualisation
• More work towards proper hardware drivers

I’m having a lot of troubles with the local authorities and a couple of issues with things like uploading photos on the new site (works ok from my development machines but not phone…), but in good news I’m still managing to get new test hardware from China.

A couple of models of motors arrived this last week, I’ve got a surplus of boards for doing more extended testing once I can get a proper workbench set up somewhere, and I’ve already paid early for a discount on a new high performance board (the Titan) I’ll hopefully be ordering very soon. (UPDATE: Okay maybe the preorder vouchers were cancelled? Waiting to hear back from the reseller about what’s going on with that launch.)

I’ve now written some replacement code for PLIC (the interrupt controller on RISC-V) as well as some new code for toggling GPIO pins but this is left to be tested & finished another day.

A full device driver kit will come later but I figured access to GPIO pins would be the most useful driver overall! I’ve found a bit of reference information for GPIO on a couple of devices and I’ve only implemented limited support for one so far but it should be straightforward to get some GPIO going on different devices as long as I can find enough information.

I’ll need to decide on some API for GPIO access before this will be usable from user programs or from other drivers. The other important part needed to get some drivers working is some mechanism to configure devices from the device tree info, at the moment the system parses the file but doesn’t do much with the information except for detecting memory, so it will at least have to pass on some base addresses or other info to individual drivers.