The X15 operating system

The only way (…) is to encourage a software culture that knows that small is beautiful, that actively resists bloat and complexity: an engineering tradition that puts a high value on simple solutions, that looks for ways to break program systems up into small cooperating pieces

Eric S. Raymond, The Art of UNIX Programming

X15 is a project for an open source operating system, structured into a stand-alone microkernel and a Hurd-like userspace operating system. The userspace operating system is intended to be general purpose, whereas time/resource constrained applications may be built directly into the kernel, omitting userspace entirely if not needed.

Source code : https://git.sceen.net/rbraun/x15.git/

GitHub mirror : https://github.com/richardbraun/x15

Documentation: https://www.sceen.net/~rbraun/x15/doc/intro.9.html

IRC : #x15 @ Freenode

The X15 microkernel

The microkernel is intended to be stand-alone, or run the userspace operating system on top of it. Development focuses on performance, scalability, real-time behavior, and portability, on cache-coherent multiprocessor machines. It is meant to be extremely configurable, in order to scale from cheap processors with little memory and no MMU such as ARM Cortex-M0 up to high-end x86 machines using dozens of processors and hundreds of GB of memory. Its interfaces allow users to easily plug custom file system, networking, or USB stacks.

Current development focuses on :

  • Complete real-time behavior
  • ARM port

The X15 operating system

As a Hurd-like operating system, it is intended to be a general-purpose multi-server operating system, running on top of the X15 microkernel, where the VFS (Virtual File System) acts as a decentralized service directory.  It is not intended to be compatible with GNU/Hurd, but will provide direct POSIX compliance, without an additional layer of emulation.

Here are the most important benefits of a Hurd-like system :

  • Extensibility: system services can easily be added, removed, or replaced, usually at runtime without restarting and, whenever possible, without requiring root privileges. For example, think FUSE but not only for file systems.
  • Security: each instance of a system service runs in its own address space, with its own privileges, and the total amount of critical code is low and can be audited. For example, an attacker exploiting a bug in the networking stack is still severely restricted.
  • Robustness: if a non-essential system service fails, the system as a whole isn’t compromised. Services can even be restarted, sometimes transparently. For example, if a network interface controller driver crashes, the networking stack gets an error and reopens the underlying network device, transparently restarting the driver, without dropping any socket.

Developers should also appreciate :

  • Debugging: since most system services run as regular userspace processes, debugging tools can be used on them the same way as for any other common application. For example, you can use the GNU debugger when developing device drivers.
  • Languages: since most system services run as regular userspace processes, they can use libraries and runtimes the same way as any other common application can. For example, provided the appropriate bindings are available, device drivers can be written in Python or Java.
  • Virtualization: by forcing programs to request system services through capabilities, namespace isolation and location independence are naturally provided and simplify the construction of features such as containers and virtual machines.
  • Customization: the system is built around a microkernel and a few essential servers, but other servers can import code from other projects. Users can choose what implementation they want to run and what interface to expose. For example, developers working on an embedded system could run a Linux-based networking stack, providing Netfilter, or a NetBSD networking stack with pf. They can even be run concurrently, either completely separately, or combined with VPN features.

Although the design of the Hurd is promising and attractive, its implementation has a number of severe issues. X15 takes the approach of the complete rewrite to make sure that key ideas are kept in mind at all times during development. Since it’s not meant to be compatible with the Hurd, critical interfaces such as IPC and signals can be re-implemented completely differently. There is a lot of emphasis on code quality and ease of maintenance, obtained from disciplined application of best practices.

Development hasn’t started yet on the userspace system.