RyukOS is an embedded real-time operating system that implements a novel socket-oriented system call interface. Through the socket API, RyukOS is able to provide a familiar interface, robust inter-process communication, and real-time task scheduling while minimizing expensive context switches.
There are four places where one may find my notes and documentation as I slowly churn out bits and pieces of RyukOS.
The final place to get a foray into the RyukOS design process is my notebook and the half-inch-thick stack of loose pieces of paper coated with notes about ideas, requirements, and whatever else I might have scribbled down at a moment's notice. I can't even read half of it anymore. This is the kind of asinine process that's going to keep me out of the big time for the entire extent of my career, but whatver. It works.
Plan9 and UNIX have files. Redox has URIs. Windows has spaghetti. RyukOS has sockets. Almost all system calls are made through an interface similar to that of the ubiquitous Berkeley sockets.
Consider the oddities that arise when directly addressing an IO pin through a file-oriented API:
Because RyukOS talks to a lot of different hardware peripherals, many of which are meant to communicate with other devices, a connection-oriented system is guaranteed to pretty closely match many of the functions the RyukOS kernel will need to perform on a regular basis.
There is nothing implicit in a file-oriented structure that facilitates real-time input capture. In a real filesystem, there is typically one task in control of that file at a time- if the file's content changes, it is implicit in the nature of a file that this change must have come from the writer of the file. However, a digital input pin changes according to external stimulus. If a task needs to quickly respond to changes on a digital input, it must regularly poll the same one-bit file, over and over, until it sees a change- not the best allocation of resources in a real-time system. However, in a socket-oriented system, where system resources are exposed as servers, a low-level digital IO server can take all requests to "listen for changes on pin X," and ensure that those tasks get scheduled when needed. This eliminates needless context switches without sacrificing the responsiveness needed for a real-time operating system.
Files simply don't exist on many embedded systems. Those that do have files may only have a small handful of them. As such, these gotchas of things-that-aren't-files in a file-oriented system overwhelm the advantages that a file-oriented system may otherwise offer to the user. Furthermore, with files comes file paths- long strings with a length that can't be pre-determined. With a socket, I can be highly restrictive about the amount of memory used to namespace things, without it feeling restrictive. It's still just the plain old sockets we've always known, after all.
The socket interface allows dynamic creation of new types of address families, by binding a socket of the AF_AF address family. Thus, low-level machine facilities can be loaded and unloaded. RyukOS is extremely primitive as a whole (give me a break, it's my first time writing an OS and I haven't even gotten halfway through college yet), without any concept of processes (only threads), so the depth to which this idea can be explored is quite shallow. However, it is a proof of concept- its design is brutally simple and it is enough to show that this just might work. This is an idea that the creators of the socket interface brushed shoulders with when they conceived of the AF_UNIX address family, which facilitates connection-oriented inter-process communication. Since RyukOS doesn't have processes, this is sort of a moot point. However, because RyukOS is meant for systems that have extremely limited computational power, yet still have a ton of little bells and whistles, RyukOS is a great place for testing out dynamic creation of device drivers. The Cortex-M4 I am using offers a slew of zany hardware features (the complete reference manual is nearly 3000 pages, about 2700 of that is discussion of hardware peripherals by my reckoning), yet offers scarecely more computational power than a Pentium Pro. This gives me the ability to thoroughly test the idea of dynamic drivers, but if I become complacent and write inefficient code, the platform will be punishing.