u/JescoInc

Perdition-OS is a complete overhaul of Tutorial-OS where I took portions of the parity C and Rust code to generate a clean split in responsibilities and a well defined FFI layer. The Vertical HAL architecture has been massively expanded. Watchdog implementation, SMP with accessing all cores on the system, Work stealing scheduler, separation of kernel mode from user mode apps, PDF renderer, PNG and JPEG rendering, FBX rendering (partial implementation based on concepts seen in UFBX), user mode apps can only be written in Rust and a topology system for being able to view what hardware exists and how they function.

The UI is still early and subject to change, however, I personally really like the design as it gives detailed information that is rarely exposed.

The rationale for this is that there is a clean separation between systems and should be a project that will help guide someone towards building an OS of their own. I focused more on the "boring" apps because to me, it is something that would make the average person care about the OS for their SBC and give them a starting point for forking and making the OS handle the things they care about.

Just in case the embedded player isn't playing for you, here's the video link:
https://youtu.be/vP8qLRjq3Wg

For me, it would probably be a tie between Fedora and Ubuntu. I used to really like both of them in the 2000s. The last time I looked at them (6 months ago), I didn’t like the direction the GUI had gone for the general release and they felt heavy/ clunky to use.

The majority of these circlejerk questions tend to be political in nature, but there are some outliers where it is people asking about something they haven't read but pretend they understand the premise.

This should be the final question of the series. It was enlightening to see people's answers to:
https://www.reddit.com/r/osdev/comments/1uag4am/which_part_of_osdev_would_you_consider_to_be_the/
and
https://www.reddit.com/r/osdev/comments/1ubhewx/which_part_of_osdev_would_you_consider_to_be_the/

My answer would be the framebuffer. Because I am not constrained to follow the textbook method. I can do hand crafted fonts, a custom font system or ttf fonts, I can do 2D and 3D inside of my framebuffer. I can choose if I want to do single, double or mixed buffering techniques. I can choose to implement Xiaolin Wu, Gupta-Sproull, Lanczos Filtering, or Bresenham's algorithm for line aliasing, line anti-aliasing or image scaling. I can choose to implement physics to the render system as well for bouncing, ropes and so on.
There's just so much freedom and fun with how you can build your own framebuffer system compared to other aspects of OSDev.

Since I asked the inverse here https://www.reddit.com/r/osdev/comments/1uag4am/which_part_of_osdev_would_you_consider_to_be_the/

I wanted to see what the consensus was on this version of the question.

This is actually the harder question to me and if I were to answer my own question, (pause for 5 minutes to deliberate) I'd probably say the second stage bootloader with the handoff to the kernel.
The reason this is the easiest to me, was because I've essentially used the same assembly code across multiple different iterations of the project and predecessors. It is basically, set it up once and you are good to go.

For me, it is the unique challenge of figuring out how to handle paging with multi-arch which takes advantage of the HAL architecture I have in place (split by SoC, Board and CPU).

Although, Net stack (Ethernet Drivers with TCPIP/ UDP / Tunneling) and USB are top contenders. Audio being ranked below those two but still is absolutely ball busting.

The reason I put paging above those isn't necessarily the difficulty but simply due to x86_64, RISC-V and ARM64 all doing something slightly different at the hardware level with the page-table formats and MMU semantics differing (x86-64's 4-level tables, ARM64's VMSA/TTBR, RISC-V's Sv39/Sv48 and satp) and needing to design around that in a clean and deliberate manner.

I was thinking. A lot of people jump to "MY OS RUNS DOOM!!!"
However, I personally find that to be a cheap win for showcasing your OS (it is one of those things where a lot of people jump to that but it isn't really a showcase of something an average user would care about or wow them) , I want to think of things that are "boring" but are a true showcase of your OS doing something.

Here's a few things I was thinking about for showcase pieces:

Rendering PDF Files
Rendering JPG and PNG files
Playing WAV audio files

Anyone else have other "boring" showcase pieces?

Edit:

Yes, I am talking about your own primitives and implementing yourself, not porting.

I wanted to make a post specifically about QEMU because so many OSDev post utilize it almost exclusively. My view is that it is a glorified validation test that it COULD work on real hardware, but not as a showcase of your project actually working.

I've done QEMU tests with Perdition-OS (Formerly Tutorial-OS) early on in the development, but when I moved to actual hardware, things that worked perfectly in QEMU, didn't on the actual hardware.

This led me to having to devise various testing strategies for the actual hardware at different levels, such as breadcrumb text, pixels at specific locations on the screen, and UART / RS232 logs depending on if the hardware had UART / RS232 available on it or not.
Basically, if you post a video about a feature working and the video is QEMU, I hold a very skeptical view of the project.

One, because it isn't validated on real hardware and Two, because AI (LLM) driven OS projects immediately jump to QEMU. Which means I have no way to being able to discern how much work was actually put into the development and design side of things that people post. (And i'm not Anti-AI).

Why am I skeptical whenever I see QEMU nowadays? I distinctly remember seeing something that someone did and I was like, "I need to look at the source because it looks like something I could use", only to find in the readme that it is QEMU only or they built for x86 but only tested with QEMU.

I also asked Claude 4.8 to give me a minimal implementation and explanation of a Micro-Kernel so I could see the difference and understand the rationale of the design for reference, and Claude immediately made a QEMU demo.

Alright folks, Since I will be adding Kernel and Userland split, I know I should also add process containment to it, so which method of process containment would you guys recommend for a monolithic kernel.
I really like how BSD did the Jail system and was thinking about taking that concept and using it since I had a previous project where I experimented with attempting to bring jail-like isolation to Windows in a userland security application. Meaning, it wasn't a real jail system, it was trying to mimic it with the software (failing miserably in the process) without having kernel mode components attached to it but I am all ears for other concepts.

https://www.dfrobot.com/product-3119.html

So I purchased this and it is set to arrive in about 5 weeks. I ofcourse had to be a bit... "Extra" and also buy a second MU with the N305 CPU in it.

I figure, I am probably going to be one of the first people to get this board, so I would love to hear what you guys would want me to showcase with it. Because let's be honest here, the asking price for it is pretty steep and I know people are less likely to buy something without having a reference for tasks they'd want to use it for.
So, what type of tests would you like for me to run on it? Gaming? LLM inference? Windows? Linux?

https://preview.redd.it/ffk6tmapb76h1.png?width=1804&format=png&auto=webp&s=9d20be4fb6b0ed6af32cea905810b681237009ad

I have a 3 year old son, he's starting to get better at talking and I do want him to learn at least a little bit of programming.
I'm not going to do it with modern programming hardware, I have a Commodore 64 with the datacette and Floppy Disk Drive as well as a TI99/4A with a casette player. This includes having educational software for them.
I figured that teaching him TI Basic or Commodore Basic would be the route to go as it is simpler and arguably much more rewarding and fun on these classic computers.
But, the problem is, I don't know what age it would be appropriate? My current thought is around 5 years old, when he can understand how keyboards work and can use the classic machine for fun and learning but I would love to hear other people's thoughts.

Note: Yes, I am a professional programmer and do have a teaching background. So teaching isn't difficult for me.

The creation of the OS for this book, which was originally named Tutorial-OS and is now officially called Perdition-OS has been the most difficult project I have ever worked on. The code itself wasn’t the hard part; it was the architecture that made it difficult. I have rewritten the OS multiple times for various reasons, but with each change, I also looked at the core architecture and decided that it needed to change.

It has always had the HAL (Hardware Abstraction Layer) but how it was expressed has changed with each iteration to cover gaps I left in the previous version. Then there was the last iteration which I realized that I didn’t separate the SBC, Board and CPU / Module correctly; Which led to having to rewrite code where the board was the same, but the CPU was different.

I improved the memory allocator between iterations as well; it began as a TLSF inspired allocator which only had the first half of the TLSF spec implemented. The later iteration went all in with TLSF and conforms to the TLSF 2.0 spec. With that change, I also included a full-on memory map implementation that walks the dtb tree for ARM and RISC-V and pulls in from UEFI with x86.

Drivers were another thing that changed significantly between iterations. Where each driver was reimplemented per board, which caused a lot of code to be rewritten for each board. The latest version abstracts the core driver from the board specific implementation making it a generic driver that needs only small portions that are hardware specific to be implemented per board.

These are but a few things that make bare metal programming difficult. The code for the most part is straight forward with the exception being how to layout the structs and memory regions. Getting the architecture for what you want to do to be sound and easy to expand upon is where the difficulty lies.

Now, there is one thing in this OS that others don’t have in the same manner and that is the topology abstraction. It isn’t that the concept doesn’t exist, but it is normally built for each peripheral instead of being its own thing. I wanted to expressly have it as its own thing specifically to power the hardware inspector and have a uart / com readout of the systems for early failure mode detection and for a robust hardware inspector.

To put it in fancy marketing terms, this topology system is different from other OS implementations because it observes in the absence of work. It finds what’s wrong before anyone uses it.

Here is exactly what I mean. This (screenshot / text snippet) tells you more than a description could ever do.

https://preview.redd.it/kpnenis12e4h1.png?width=935&format=png&auto=webp&s=2ddd722d235bb1a9905173a3ca22d8f56d88cdc0

This expressly tells us that the memory region failed to init properly and went to a fallback. It also tells us that only 1 CPU was detected and will only run in single-core mode. No USB mouse or keyboard was detected. Clock, Power, DMA, IRQ, and Thermal nodes / rails / groups / lines / channels / zones were read as zero, which implies not found or not yet implemented.
Which is a dead giveaway that things were not fully implemented for x86 and we weren’t reading from UEFI correctly.

Now, let’s look at the current iteration of the KYX1 system. This (screenshot / text snippet) is a deep showcase of the true power of this topology layer in action.

https://preview.redd.it/sn4qnis12e4h1.png?width=296&format=png&auto=webp&s=6ae1cf5fd4bb1b92e25e7f483358941f97b0eeaf

This one has a way more information to display than the LattePanda one had, but there is also a very sinister bug hidden that was surfaced by this topology layer that wouldn’t be caught by stress test or standard debugging. The pll1 says the rate is 0hz, that means that the clock framework isn’t being read correctly which points to a flaw in the implementation code. This would bite us later when we are trying to show proper clock speeds or modify clock speeds.

Edit:

Links to screenshots so you can actually read them:
https://github.com/RPDevJesco/Tutorial-OS-Book-Excerpts/blob/master/LattePanda_Early_UART_Topology.png
https://github.com/RPDevJesco/Tutorial-OS-Book-Excerpts/blob/master/kyx1_early_uart_topology.png

In the dream, I was working on what looked like the Linux source code and was talking to someone. Those details are a bit fuzzy, but what stood out to me was in the dream, the code had a particular separation that not even my OS project has but will here shortly because it makes sense in the real world.

There were folders designated for different SBC (single board computer) boards, but the CPU details were curiously not there. Instead, there was a separate set of folders designated for CPU.

I do remember that in the dream this was being discussed and it was because different versions or revisions of the boards can have different CPU. In order to reduce duplicated code, it was set up that the build process would allow for pairing the board with the correct target CPU.

I was mulling over this today and realized that this is actually accurate and the way I should actually be building my OS. Why? Take for example the LattePanda MU, it comes in N305 and N100 variants and they work on the same carrier boards. Look at the Nividia Jetson Xavier carrier board and CPU, Milk-V Jupiter NX fits on that very same carrier board.
The list goes on and on where the CPU can be swapped for carrier boards and if you pair the CPU directly with the board, you'd have to duplicate code to handle that scenario.

This was basically just one of those instances where a dream can influence or change designs because it mirrors real world scenarios and is an instinctive solution to a problem that may not have come up in the work yet.

Edit:
I am aware this is how Linux and BSD mostly does this, but it didn't cross my mind to do this with my own work until the dream occurred. It made me take a step back and reevaluate what I was doing, what my goals were and whether or not it solved a real or imagined problem. In this case, the problem was real, even in the SBC space and I needed to properly solve for it to reduce code duplication.

Luckily for me, this doesn't involve a massive amount of changes or core architectural shifts. It does mean I have to spend some time revising my build rocess and makefiles as well as shifting locations and names for files.

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.