Example: parts of the execution layer for emulating (distributed) user processes and distributed filesystems
Athomux is an experimental operating system developed at the University of Stuttgart in the early 2000's by Thomas Schoebel-Theuer and a few students (mostly German Diplomarbeit / equivalent to Master's Theses). The first publication was in Autumn 2004.
Development of the sourcecode (GPL + LGPL) is discontinued now.
However, many concepts from Athomux are living forth in the MARS project, see https://github.com/schoebel/mars.
In particular, Athomux was the first Instance Oriented (operating) system, while MARS is now the second-generation approach to Instance Orientation, athough more focussed to storage systems.
Athomux was a "proof of concept" that you can build an entire instance oriented operating system out of only two basic abstractions, but remain Posix compatible at the userland interface. The maturity level of the implementation was comparable to Unix in the early 1970s: a simple shell was running, processes could be fork()ed and basic filesystem operations were possible.
Many lessons learned from Athomux are now extremely helpful in the development of MARS.
The second generation of Instance Orientation and its improvements over the first generation will be described at the MARS site. This page is about Athomux and the historical development of Instance Orientation. You can find most Athomux papers and IOP papers here.
Athomux promoted an advanced construction principle: the whole system was constructed according to a LEGO-like kit, out of many (small / lightweight) bricks which are nearly arbitrarily combinable with each other.
The medium-term goals behind its architecture were beyond the functionality of contemporary mainstream OSes like Unix, in particular it aimed for a true distributed OS where it really doesn't matter on which host you are logged in. One of the Diploma theses showed (as a proof of concept) that this goal was reachable at a very generic level thanks to Instance Orientation.
The (very) long-term goals were seamless integration of operating systems, databases, distributed systems / middleware, and others.
Athomux was also some kind of "meta-middleware". It could be used as a construction kit for building middleware and as a research platform for Organic Computing systems.
The whole system is composed of brick instances. Bricks have a varying number of inputs and outputs. Bricks resp their inputs / outputs are interconnected by wires, forming a circuit-like network of instances. There is only one single interface type called nest, similar to the standard tenons of LEGO toy bricks and their respective female socket counterparts.
As a very rough metaphor, a brick is like a "virtual storage device", and a wire is like a "virtual USB cable". Bricks have inputs and outputs, like male and female USB sockets at a USB hub, while wires are like USB cables with male and female USB plugs at each end.
More precisely, a nest instance provides generic access to (virtual or physical) memory, but in an abstract way (as an approximation, you may think of it as (1) some sort of "virtual file" like those in the /proc filesystem of Linux which "creates" its "contents" on demand, or (2) as an abstract base class of OO which has however no publicly visible derived classes).
Bricks may act as transformers between nest instances.
Bricks may be implemented stateless or pseudo-stateless, alleviating advanced functionality like
The instantiation of bricks itself is again controlled by bricks (in recursive fashion). Control over instantiations is performed via strategy nests. A strategy nest "contains" an abstract representation of a network of bricks. Strategy nests may be created and manipulated by strategy bricks, possibly acting as transformers on/between different strategy nest instances. This allows multiple views onto the system in parallel.
This may be used to create virtual views which need not exist in "reality". Its full application potential is not yet clear; probably it may be far beyond the functionality what people (including me) can currently imagine what an operating system could do for them (including me).
The principle behind views and transformers is called
Although Instance Oriented Programming (IOP) is principally independent from other progamming methodologies like Object Orientation (OO) and can be combined with it, Athomux is not object-oriented. It is more similar to an architectural style known as "pipes and filters style" in software architecture.
Further important principles are universal genericity and compositorical genericity (see my papers). The nest interface aims to be universally generic (thus enabling a very broad application area). Composition of brick instances directly resembles compositorical genericity. As shown in my papers, its potential for reduction of redundancy is far better than the potential of OO extensional genericity.
While current OO design methods tend to create a large number of interfaces, the Athomux principle of re-using a single universal interface type for almost anything is very different from that.
Currently, most of the infrastructure is at a usable state for developers.
The Athomux preprocessor and its input language (a superset of C) is not yet fully stable, but it automates a lot of tasks (which would otherwise be extremely tedious, if not nearly impossible). It has proven its value for rapid prototyping, while retaining good performance of the generated C code.
[Addendum: the Athomux preprocessor was an early ad-hoc attempt for creating an instance-oriented programming language.]
The current Athomux prototype runs in Linux userland, using pseudo device-drivers. [later, a Diplomarbeit implemented standalone booting on bochs such that Athomux ran as a "standalone kernel", and another Dimplomarbeit implemented instantiation of Athomux bricks in the kernel address space of the Linux kernel -- out of the same source code (where possible, i.e. when the brick was not system dependent)]. It implements only a few rudimentary parts of the OS: a prototype of the filesystem, and (thanks to Florian Niebling) a prototypical dummy-MMU brick (where inside the backbox actually a Linux process is running statically linked uClibc binaries) operating on prototypical Athomux bricks for emulation of the most important Unix system calls like open(), close(), read(), write(), fork() and exec(). Although not yet aimed at providing full Posix functionality, Flo's work is a big part of the proof of concept. Many thanks to him!
Some device drivers are being ported from Linux by Jens-Christian Korth. His task is to allow Athomux bricks to execute in Linux kernelspace (such that the whole Athomux system appears as a single Linux kernel module) without any modification of brick sourcecode (except system-specific bricks like drivers). At that stage, Athomux will be hosted by the Linux kernel, using the device drivers from there. Hopefully some infrastructure for a true standalone Athomux system (in particular thread_* and cpu_* as well as true device_mem bricks) will emerge from that.
However, the next short-term goals will address networking in preference to a standalone system. While a standalone Athomux version (no longer running as a guest in kernelspace of Linux) does not provide any novel functionality per se, a transparently distributed version of Athomux is the next more important goal. Since it can be solved at a very generic level, I hope that it will not take too much time to demonstrate some functionality beyond current mainstream OSes. [Yes, that became true later.]
Stuttgart, September 2004,
Dr. Thomas Schoebel-Theuer
New!
29 October 2004: the University of Stuttgart has permitted the
publication of Athomux "as is". This means, it can appear under GPL and LGPL.
Anonymous checkout is already possible via the command
svn checkout svn://svn.berlios.de/athomux/trunk
Notice that the initial release contains only code written by me; the work
of Flo and Jens will be integrated within the next few days or weeks
(now we have the permission from the University).
If you want to join the project, just ask me.
Only for developers: please use the subversion URL
svn+ssh://svn.berlios.de/svnroot/repos/athomux/trunk
in order to get write access.
Impressum:
Dr. Thomas Schöbel-Theuer
Europaplatz 4
D-70565 Stuttgart
ts@athomux.net