We try native Inferno OS on Raspberry Pi

I present the working port of Inferno OS for Raspberry Pi .

For quite a long time, it was not so easy to try Inferno OS as a “native” OS and not in the “hosted” mode when the system is launched as a process on Linux / Windows / MacOS / Plan9. The main problem is the lack of a wide range of drivers for the main platforms and the easily accessible “hosted” mode.

')

First, it probably costs a little to open the veil and say what Inferno OS is and how good it is (The first thing they ask in the comments! On Habré, there has long been an excellent cycle of Russian-language articles from powerman: list , also his blog ).

Everything is a file

Inferno OS system is the ideological successor of Plan9, so the simple concept is clear: everything is a file. That is, the notion of API in some sense can be omitted. For example, the TCP stack is virtual files, interacting with which new connections are opened, and data is transmitted via writing / reading files. Environment variables - directory / env where files are environment variables, and so on ...

Namespaces

Each process can create its own environment for itself and its descendants - do you need a sandbox implementation without a network for applications? - simply removes / net from the environment of certain descendant processes. Since all interaction with the system, other applications and the environment is done through synthetic files, then by juggling with the environment of applications, you can implement a diametric approach to application development - it’s not the application that tries to adjust to the platform by analyzing the environment, hardware, software, but rather the system allows you to customize the environment applications.

Dis, virtual machine and platform-independent bytecode

Dis is a rather interesting byte-code that “implements” the processor without registers, that is, asm commands of the Dis are commands of the form mov mem1, mem2; add mem1, mem2, mem3; The transmission of such commands (JIT) is very fast and efficient, since each Dis instruction corresponds to only a couple of commands of the platform processor. There is even a project to translate java bytecode to bytecode Dis. In terms of performance, the lag behind the same C program in the tests was shown as only 1.6-2 times (I want to reproduce such testing soon to confirm the results)

Security

The system of access checks as a result boils down to managing access to files - the headache of checking hundreds of different APIs for vulnerabilities disappears. This does not mean the absence of vulnerabilities, but provides a significant simplification of the security system as a whole.

Programming applications using the concept of Communicating sequential processes

When programming applications for Inferno OS, light threads are used, channels - everything with which Go came. But unlike Go and Erlang and the like, there is a fundamental opportunity to turn any application channel into a synthetic file. As a result, each multi-threaded application is easily split into separate processes, applications, and, if necessary, easily transferred to different hosts. That is why the main practice of writing applications is not a “unixed” unix-style application that expects stdin , processes data and outputs results to stdout, but a file server-style application that has virtual (synthetic) files for incoming data, controls and virtual files for output.

Universal Network Interaction Protocol - 9p / Styx

A very simple and effective protocol for organizing the connection of various components. Only one design feature - sensitivity to delays.

If Inferno OS is so good and easy to run in “hosted” mode, then why do we need the “native” version?

Here is the most interesting point: in the last couple of years, interest in the Inferno OS has awakened, but not as a user system but as a system for use in the “Internet of things” infrastructure. Oddly enough, it is precisely inferno as a compact operating system with a universal 9p / styx protocol for access to everything and managing everything and a universal Dis code is ideal for embedding and using in this niche.

Many SoCs now have what can be called an “excess” of computing power for the tasks for which they are intended. Therefore, technologies such as Dis / Limbo / Styx have an advantage even at lower performance than C counterparts. Plus, there is always a simple opportunity to bring the “computational” part to the C-level of the core. But 9p / Styx makes it easy to implement the interaction and integration of dozens and more inferno-devices into smart networks, it is easy to forward calculations between devices and so on ...

Now about the port itself.

The port was launched slowly and more just for fun. And I did not expect that it will result in a full-fledged port. The main goal that I set is to document the porting process in the form of a lab in order to simplify the adaptation of the system to new chips as much as possible. After receiving “Spherical Inferno in Vacuum” (season 1, no drivers at all, but with timers for switching processes, etc.), it turned out that a lot of drivers can be easily adapted from the Plan9 project for Pi (9pi) - it took the second season and brought the port to state to run fully on the RPi with the network, keyboard, mouse and graphical environment.

It turned out that porting the system to another ARM chip is pretty easy.

As a result, there is now an easy opportunity to sample and study Inferno OS exactly as a “native” system on iron. Since the system is very compact, the code is easy to learn (part of the code is shared with Plan9), this operating system is easily modifiable just for research tasks (I have a couple of hot ideas!). I think many researchers in the field of operating systems will be interested.

Ps. For some time this wasp was said to be forgotten. Many architectural solutions in this system turned out to be ahead of their time and simply unclaimed. Now it seems the situation is changing with the advent of "internet of things".