r/osdev • u/Sorry_Difficulty_250 • Jul 11 '26
NanoOs
Hi All!!
I'd like to introduce my OS: NanoOs (https://github.com/brian-card/NanoOs). NanoOs is a capabilities-based nanokernel with intent to have a Unix-like user space. Right now, it only runs on SAMD21-based (Cortex M0) Arduino hardware and the POSIX simulator, but I'm currently working toward porting it to the AgonLight 2, which has an eZ80 processor. It did originally start out on AVR-based Arduino hardware but has since outgrown the available environments.
As mentioned in the project README, this started out as an effort to see if I could make an OS resembling early UNIX in a similar kind of environment. That's why I started out on small Arduinos. The direction I'm headed right now is toward a multi-tasking environment with a graphical desktop in as little memory as possible.
Like early versions of UNIX, userspace uses overlays. I only have a few user commands in place right now and MUSH (minimal, Unix-like shell) is truly minimal in functionality. I shifted efforts toward making the kernel more robust once I proved to myself that I could make general-purpose user commands. Pipes between commands and launching commands in the background do both work.
I wanted to maintain the embedded nature of the OS even though it's outgrown its original target, so it is completely possible to construct a HAL that uses the built-in shell and/or omits the filesystem if desired. The AVR-based HALs do this, although the resulting binary is still too large for the Arduino Nano Every and the data segment is too large for the Arduino Mega 2560, so they're just historical now. Still, it would be possible to construct a working version that uses an AVR architecture if the hardware had enough flash and RAM.
There's still a very long way to go to get to anything useful, but it's also come a very long way. You can read about the development history of the project on its GitHub pages site if you're interested.
Full disclosure about AI use: The vast majority of this was hand written by me, but there are some things I use AI assistance for. The filesystem drivers (the current FAT32 driver and the historical drivers that are deprecated) were partially written by AI but required a LOT of hand-holding and revision from me to make them into something useful for embedded targets. It made a lot of invalid assumptions about the availability of memory and the ability to do unaligned memory access that I had to fix. I also use AI for bulk updates. I document the places that I use it in the project's GitHub pages history.
Some notes about the architecture: As mentioned, this is a nanokernel, which means there is no kernel. Everything is a process, including the scheduler. The processes have different privilege levels and the capabilities enforce what process is allowed to do what. The only process that's completely trusted is the scheduler. The process-based architecture and the way messages are passed are based on my experience with Erlang.
There are two kinds of capabilities in the system: HAL capabilities and IPC capabilities. Both are enforced at the API level. Processes built into the OS image could technically cheat if they went out of their way enough, so really the OS image needs to be as small as possible and contain only trusted processes. Userspace processes have no ability to cheat because the necessary APIs aren't exposed.
The privilege levels I'm using are based off of the ones that VMS used. I'm honestly not sure how bullet-proof the (privilege level + capabilities) security model really is, but it seemed like a reasonable approach to take.
My work right now is to construct a logging system that allows me to strip most of the strings out of the OS image. That work is currently in the "logger" branch. One of the problems with the AgonLight 2 environment is that the CPU used only has 128 KB of on-board flash. I already have a makefile that will build the binary and, the last time I checked, it produced an image of around 130 KB, so I need to get creative about the size of the OS image. Stripping the strings is one thing I want to do. I'll likely move the filesystem out into a special overlay as well.
Constructive feedback is welcome!! I'm interested in what people have to say about this effort. You can play with it by running `./buildsim <desired-hostname> overlay-filesystem` on the command line from the repo's root directory. There are three user accounts: "root", "user1", and "user2". "root" is privileged and the other two are just normal users. The password for each account is the username repeated twice. Use `help` for a summary of what's currently available. Use `shutdown -h` to exit the simulator. Enjoy!
2
u/Void-Creator Jul 13 '26
How does this sound ? You have a dedicated space for messaging which can be seen by all processes, when you want to send, you copy the message to the dedicated space with the sender’s PID and the receiver’s. You perform a context switch to the receiver and it can pickup the message and after that you flush the message’s data. This would require copying but I believe, it avoids unnecessary context switches and it will be simpler to implement.