u/JescoInc

https://youtu.be/fca1CWhH9E8

This demo showcases https://github.com/magiblot/tvision being used with this OS (which I have dubbed PersonaOS). The main selling points of this kernel architecture type is that you can have multiple "personalities" running in tandem. That means you can have a BSD personality and Linux personality that can run applications written for those operating systems natively.
You have 1 tiny core kernel that runs with elevated permissions, everything else is usermode. This includes the personalities, drivers and applications.

This has been implemented following this paper: https://www.usenix.org/conference/osdi-94/caching-model-operating-system-kernel-functionality

Yes, obvious bugs are obvious. But getting an unmodified TUI application to run has genuinely made me seriously happy.

My question for you fine folks, is simple. Do you have SBC readily available? If so, what do you have?
The idea is that I want to make a demo to share that works on hardware that the majority of you guys own.
Yes, I know I could do QEMU, but I don't want to go that route and there are valid reasons why I don't want to release it as QEMU for discussion.

The OSDevWiki mentions a Cache Kernel type. The exact verbiage is:

"The Stanford cache kernel caches kernel objects, like address spaces and threads, and allows usermode “application kernels” to manage them, loading and unloading them as needed. Application kernels manage their threads' page faults, exceptions, etc., and the cache kernel allows several of these application kernels to coexist in a single system."

Unfortunately, that link was dead for me, which sent me on a little rabbit hole of research.
To which I came across: https://www.usenix.org/conference/osdi-94/caching-model-operating-system-kernel-functionality

I'm currently in the research and understanding phase of this type of kernel because there don't seem to be any examples of it being implemented in the wild anywhere that I could find. I looked on GitHub and other online / public repository spaces to no avail.

I'm thinking that I should be able to take some of the code from tutorial-os and adapt it once I have wrapped my head fully around the concept while being able to reuse one of my SBC for this (I'm thinking the KYX1 as it is the board that is most fresh in my memory).

So far, my reading of this document has surfaced these key points about it.

The Cache Kernel caches four descriptor types and nothing else. Those being:

1. Kernel objects
2. AddressSpace objects
3. Thread objects
4. MemMapEntry

It essentially treats kernel objects as cached copies of state the application kernel owns.

Further investigations provide a rather interesting consequence of this design:

You can have different ABI / SBI kernels, meaning, you could make kernel personalities that run different processes side by side and mutually isolated. Like say, a kernel personality for Unix (BSD) and a separate one for Linux, compile user applications for those and it would just run.

The reason for this is because Cache Kernel Architecture is essentially a kernel that loads another kernel that loads user applications.

Essentially, I am trying to come up with a way to where most systems and drivers can be "spun down" or brought up through commands or some other mechanism but not leave the OS in a state where it would crash and needs to be safe to do via user mode with syscalls.
I know there are various techniques for this and I am trying to gauge which technique I want to use. Googling doesn't surface all techniques that could be used and I thought it would make for a great conversation.

I'm in the mid-west, Missouri. It is presently 69 degrees F (20.5 degrees C), cloudy with it about to dump another bucket of rain on us again in about 15 minutes.

For me, the concept of journaling is fascinating. Crash-Consistency is one of those things that I think are deferred until something happens, even in application and web development. In OSDev, it can be the difference between a file(s) being lost and / or corrupted and a recovery with minimal loss and no corruption (based on technique used).

This is more of a discussion topic.

I don't mean a binary that asks "Which ISA am I?" as that is a circular question because this question itself is an ISA specific act. What I mean the binary that says, "I am x ISA, where is my entry point?" because the firmware will do the selection as it already knows and acts as which ISA it is.

Let's get into it. So, with Perdition-OS (Tutorial-OS), I had gone with the tried and true approach of building my ELF files and images specifically for each ISA. That means there is a separate ELF and img file for RISC-V, ARM64 and x86_64.
Which led me down a rabbit hole of, "Can I make a single file carry more than one ISA?"

The answer to this was, "Yes, but with caveats".

combined.efi is byte-for-byte one file that's both a valid PE32+ EFI app (UEFI parses the PE, maps sections, calls efi_main, x86 over ConOut and a carrier for a RISC-V flat kernel at offset 0x10000, relinked for 0x20010000 so U-Boot's go 0x20010000 lands on it over SBI.

Nothing's decoded twice: UEFI reads only the PE, U-Boot only jumps to the RISC-V bytes. Same file in both roles.

The reason it works where an instruction-level polyglot can't: the two firmwares don't share a loader. UEFI does a structured PE load, U-Boot does a raw jump which means that each just enters its own slice by its own convention. It's the Apple-fat-binary idea, except there's no shared header any loader parses; each firmware finds its slice independently.

There is one additional caveat for this idea. It leans on the UEFI loader tolerating the overlay past the PE's declared sections, a signed or stricter firmware could reject it.

So: is this just underused, or is there a good reason it stays niche? What am I missing?

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.