u/JescoInc

With tutorial-os-definitive-edition, one of the major changes I made was to add real testing to the codebase. I wanted to adhere to the no external library, framework or dependency rule.

So, what did I do? For C, it was simply building my own assert and diag style of testing. For Rust, the built in test framework with cfg test.

With both languages, I made a specific folder where I wrote test code for most parts of the source code.

At compile time, I also have a make file that uses clippy, clang and clang for analysis of the code and generates a file for that output along with my build artifacts.

This means, I have static code analysis at compile time, a dedicated test runner on the rust side whenever I want and tests that run when the OS is loading on the device.

https://github.com/RPDevJesco/tutorial-os-testing-output/tree/master

If anyone has any other testing strategies I could use, I would love to hear about it.

I wanted to update everyone and kind of explain why I haven't been posting about Tutorial-OS updates. That is because, I realized something that was a bit painful to bring to light.
As Tutorial-OS grew, maintaining a Rust and C parallel, parity implementation was cognitively exhausting. And that was made extremely apparent when I finished the parity implementation of the glTF renderer portion.

I needed to take a step back and re-evaluate my plans and the goals I wanted to achieve.
I thought about how I am very much against the Rust in Linux design and it isn't because I am anti-rust. It is because there is no clear and well defined FFI layer that the OS adheres to, everything is basically ad-hoc based on what the maintainer wants to do.
Yes, I understand how monumental of a task it would be to take a 20+ year old OS and define that layer and adhere to it with how large of a codebase it is. I don't want anyone to get defensive or call me a hater due to my philosophical differences on this.

I decided to put my money where my mouth is and design Tutorial-OS with this clear FFI boundary where C and Rust play pivotal roles in the OS while being true to the strengths of each language.

This means, that C owns what touches the silicon directly and Rust owns the data.

What does this mean exactly?

Anything that has to know about a specific register at a specific physical address, runs before a stack and heap exist, or has to coordinate with a linker script and a specific instruction set stays in C. Anything that's "interpret these bytes," "manage this state machine," "build this data structure" goes to Rust. The FFI bridge sits where those two domains meet.

The FFI bridge has two layers, the C side and the Rust side. The C side is what you'd expect, to define what Rust can see and operate on. The Rust side however, has an FFI-Sys and FFI layer specific to that bridge with safe abstractions around it. The Rust side's allocator has to have a little bit of caller unsafe and everything else that has to be unsafe lives in an unsafe-boundary crate.

With this new version, I have also written extensive test code in Rust and stress tests in C while also utilizing Clippy and CPPCheck at build time for further coverage.

I can't wait to share the source code with everyone and I will once I have finished the rewrite and have it all working as intended on at least one SBC, the Orange Pi RV 2.

So... I think I killed my Orange Pi RV2 last night.

With my custom OS, I was running memory allocation stress tests on the C code and one of my test locked itself into an infinite loop.

The CPU got SUPER hot and after 5 minutes I decided to unplug it to reset it.

After reboot, all I ever saw appear on UART was:

U-Boot SPL 2022.10ky (Jan 07 2025 - 13:44:01 +0800) [ 0.219] DDR type LPDDR4X

Lesson learned... Add thermal management that supersedes anything and everything the system is doing.