Example: parts of the execution layer for emulating (distributed) user processes and distributed filesystems
Athomux is an open source project aiming at building a new operating system "kernel". It started as an informal research project at the University of Stuttgart (Germany), but seeks to get hosted in the open source community as well as in other research groups.
Athomux promotes an advanced construction principle: the whole system is constructed according to a LEGO-like kit, out of many (small) bricks which are nearly arbitrarily combinable with each other. This will enable a new level of flexibility and functionality.
The middle-term goals are beyond the functionality of current mainstream OSes like Unix, in particular a true distributed OS where is really doesn't matter on which host you are logged in. The (very) long-term goals are seamless integration of operating systems, databases, distributed systems / middleware, among others.
Athomux is also some kind of "meta-middleware". It can be used as a construction kit for building middleware and as a research platform for Organic Computing systems. Collaboration with/among various research groups is highly appreciated!
The whole system is composed of brick instances. Bricks are connected 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. 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 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, I try to re-transfer the copyright (of my part) back from the University of Stuttgart to me.
When the University permits it, Athomux will released under three licenses: GPL, LGPL and (probably) a "commercial" one. Users may then choose among them (dual licensing scheme).
Developers may put new bricks under any license whatever they like, but we strongly encourage people to use the three default licenses also.
For some core technologies of Athomux, patents have been submitted by me. For (L)GPL'ed usage, a free patent license will be granted.
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.
The current Athomux prototype runs in Linux userland, using pseudo device-drivers. 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.
In order to become a mature system, certainly much more work has to be done. It depends on you how fast Athomux will grow and become mature. If you are impressed by the Athomux construction principles, don't hesitate to join its development! Volunteers are highly welcome.
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