EiED Online>> The Inferno OS: A Small, Well-Kept Secret

OK, I miscounted. I was going to cover Vita Nuova’s Inferno last issue, but it took a little longer to checkout the latest version 4. The delay was worth investigating the latest nuances and features. Inferno and its associated components are available as a free download from Vita Nuova’s website. Installation is easy and worth a look.

Inferno is one of those well-kept secrets. It has its roots in Plan 9, a loosely coupled, distributed multiprocessor system from Bell Labs and AT&T. It shares many of the concepts in Plan 9 but is now under the auspices of Vita Nuova.

Inferno is a compact operating system (OS) that is built on the Dis virtual machine similar to a Java virtual machine (JVM). Its native language is Limbo, and Inferno has a just-in-time (JIT) native code compiler for performance. A system fits into 1 Mbyte of memory, making it more compact than Java and suitable for a variety of embedded applications. It runs on a range of processor families like x86, Xscale, Arm, PowerPC and Sun Sparc.

One of the primary features of Inferno is that all resources are files. This includes everything from access to a TCP/IP domain name service (DNS) to a graphical user interface.

Each application has its own name space organized as a single hierarchical directory. As with Unix-style operating systems, Inferno has the ability to mount a remote file system as a directory within the current file system (see figure). This provides an interesting mechanism for remote system manipulation.

The hierarchical directory system allows services to be partitioned by grouping the associated files in directories. Likewise, there is a single security model to contend with. Set the file or directory security attributes so a user has access and a programming associated with the user can use the associated services if it also has access to the directory. Authentication is required and encryption is optional.

An Inferno application only needs to make a directory of services available to a remote system for another application running on the remote system to access data and manipulation services by simply opening and using files that reside on the Inferno system. Application access to resources is location independent so the only difference between a local file or a remote one will be latency. Of course, providing this environment is easy if Inferno is running at both ends.

The underlying protocol to implement the communication between remote machines is called Styx. The Styx 9P2000 protocol is shared with Plan 9. The protocol incorporates authentication and encryption, a key to success for secure, embedded networks.

Styx uses a standard, certificate-based, public key encryption system. This is used when remote name spaces are mounted on a local machine. It can employ a range of encryption algorithms including IDEA, 56 bit DES, 40, 128 and 256 bit RC4 plus MD4, MD5 and SHA secure hash algorithms.

Styx protocol implementations require significantly fewer resources (memory and compute power) than Inferno. This makes it possible to implement Styx on a microcontroller, not just a PC-grade machine. The idea is not as far fetched as it may seem since such a microcontroller could be easily incorporated into an Inferno environment and the applications would never be the wiser. In this case, the microcontroller would implement any necessary file channels to provide status information and receive commands or data. An array of such microcontrollers could have their namespaces mounted by an application on another system that would control the devices.

Implementing Styx on a particular processor is not necessarily difficult but you may want to contact Vita Nuova to see if it has been done before.

Styx can run on top of just about any link including TCP/IP. TCP/IP tends to be the transport mechanism of choice for Ethernet-based environments, but it is not the only one used with Inferno.

Limbo, the programming language, is similar to C but with a module system closer to Pascal. The syntax of common statements like for are the same as with C, but there are enough differences that application migration from another language will be tedious at best. It is possible to use outside services and libraries for legacy code support. Like Java, Limbo supports garbage collection.

Limbo’s big claim to fame are channels and the associated synchronization support. Channels are used to handle Inferno files and Limbo applications make quick work of interprocess communication via the file interface using channels. Of course, the Limbo syntax takes all this into account. For example,

waits for a value on the syncchannel and assigns it to variablename. The Dis VM implements channel synchronization primitives making this type of communication very efficient. Likewise, processes are very cheap in terms of system resources making this a natural approach with Inferno.

Services are implemented as Limbo modules that an application can load as with Java classes. Typically, Inferno applications actually consist of a number of active tasks linked via channels.

Limbo has the usual collection of primitive data types including fixed point. It also has tuples (ordered collection), lists, and array slicing. Overall, a very complete language sufficient for building most applications without leaving Limbo.

I started with an overview because most of you probably never heard of Inferno although Plan 9 is probably a bit more notable. For those familiar with Inferno, we have of the enhancements in the latest version not including various bug fixes.

The Limbo language adds some new operations like CASEL and support for fixed-point data with associated changes being made in the Dis VM. The public key authentication has been streamlined, and the Tk graphics implementation has been revamped with new widgets being added. The window manager has been split out. Scalable fonts are not supported. Finally, the Styx protocol uses the 9P2000 protocol from Plan 9 that is more robust.

I found version 4 a little easier to use and much easier to setup. Still, the configuration process could be more automated for higher-end systems like Linux, Windows, or Solaris. This is less of an issue with an embedded target.

It is relatively easy to setup multiple Inferno installations under Windows and Linux and then control them by a copy of Inferno running in a Web browser. What is most impressive is the ability to remotely manipulate Inferno systems to configure cooperating applications on different systems. The transparency provided by the file-based communication system makes it possible to move applications around at will. The only real downside is configuration, which is best done using text script files so the configuration information is retained. Rolling your own configuration and management tool seems to be the norm when using Inferno.

Inferno fits into the growing realm of networked devices. It shines in networks of small systems up through grid computing. It makes less sense in a single-processor system, although its interprocess communication system can be very useful where new tasks are created often and must communicate with their peers.

Location transparency is probably the best reason for using Inferno. Rearranging the distribution of data and applications is a relatively trivial exercise with Inferno compared to the royal headache using most other approaches.

Inferno comes with its own graphical operating environment. It can even run as a Web browser plug-in. This is great for Web-based applications.

Acme, the development environment, takes a little getting used to, especially for a Windows or Linux hack like myself. Window resizing and movement are completely different, as is menu operation. That aside, the tools are complete although they lack the breadth and integration of third-party tools that is enjoyed by Eclipse or third-party development systems like Green Hills Multi or Metrowerks CodeWarrior.

Of all the aspects of Inferno, the development environment is probably the one thing that could use a boost. Inferno, Styx, and Limbo are the real gems.

Vita Nuova uses a dual license for Inferno. It’s free in the GPL (General Public License) sense, or it can be purchased for commercial distribution where your system modifications are private.

Although Inferno has not garnered a lot of press or support, changes in the embedded environment may make a difference. Networking has moved from being a PC-related phenomenon to being almost ubiquitous in multiprocessor, embedded applications. Inferno is targeted at this environment and enjoys significant advantages over alternatives such as SOAP and Sockets. An application can easily manipulate a remote Inferno device, and all the device needs to do is make its namespace available.

No more predictions for the next edition of EiED Online. You’ll just have to stop by www.elecdesign.com to see what shows up next week.