A Persistent System in Real Use - Experiences of the First 13 Years - Jochen Liedtke German National Research Center for Computer Science GMD SET 53757 SaIikt Augustin Germany jochen.liedt [email protected] Abstract more memory and a hard disk were added. In the following years the system was ported to many differ- Eumel and its advanced successor L3 are operating ent niachines based on Zilog 280 and 28000, Motorola systems built by GMD which have been used, for 13 GSOOO and Intel SO86 processors. years and 4 years respectively, as production systems Unfortunately 8-bit and the early 16-bit processors in business and education. More than 2000 Euinel sys- did not provide hardware to support a state of the art tems and 500 L.9 systems have been shipped since 1979 operating system, in particular they lacked a memory and 1988. Both systems rely heavily on the paradigm management unit. We, therefore, designed a virtual of persistence (including fault-surviving persistence). machine with a powerful instruction set and virtual Both data and processes, in principle all objects are 32 bit addresses. Although the instructions and the persistent, files are implemented by means of persis- XlMU had to be implemented in software, the sys- tent objects (not vice versa) etc. tem's overall efficiency was high enough that commer- In addition to the principles and mec1ianism.s of Eu- cial sites had up to 5 terminals per system. nael/LS, general and specific experiences are described: Due to its non-standard architecture Eumel was these relate to the design, implementation and main- initially a one language system based on ELAN tenance of the syslenzs over the last 13 years. For [Honi 791. Later, some other compilers became avail- general purpose timesharing systems the idea is pow- able (CDL, Pascal, Basic, Dynamo) but these were not erful and elegant, it can be eficiently implemented, but widely used. making a system really usable is hard work. In due course processors came up with the neces- sary hardware support for data security and virtual addressing; the requirements of the virtual machine 1 Historical background: Eumel and could then be met directly by hardware. In 1987 L3 we started the L3 development, principally aimed at achieving higher performance and obtaining an open When the first 8-bit microcomputers became avail- system. The L3 architecture is an advancement and a able in Germany, GMD started an effort to introduce generalization of the Eumel principles, but built com- them, aa small workstations, into schools and univer- pletely from scratch. Since L3 is upwards compatible sities. Since there was no really usable operating sys- with Eumel, it inherited all of the existing tools and tem for these machines (only CP/M and similar con- applictions. trol programs), GMD and the University of Bielefeld Both L3 and its predecessor Eumel are pure p- decided to develop a new system from scratch. kernel based systems relying heavily on the idea of Design and implementation of the Euniel (pro- persistent processes. They are strongly influenced by nounced 'oimel') operating system started in 1979. hlultics and have similarities to later systems, such as The initial hardware base was a computer with a Zilog Accent and Mach. Z80 processor, 64 I<B of main memory and one or more The first Eumel systems were shipped to end users 8"floppy disk drives storing 300 Kbytes each. Later, in 1980, and were mainly used for teaching program- 2 0-8186-5270-5193$3.00 0 1993 IEEE ming and text processing. In the following years com- mechanisms used to achieve this are virtual address mercial systems to support lawyers, and other spe- spaces and m,apping. Benefits of this decision are that: cialised applications for small and medium sized com- panies, were built on top Eumel. By the mid 80’s more 0 Only one general mechanism has to be designed, than 2000 systems had been installed. implemented, verified and tuned for files, pro- Delivery of L3 began in 1989 and, to date, about grams and databases. 500 L3 systems have been shipped. Most of these are used for commercial applications, others as Eumel suc- 0 New persistent data types can be built efficiently cessors in schools. L3 is now in daily use in a variety using this mechanism. of industrial and commercial contents. 0 A single, general, recovery mechanism can be con- st,ructed. 2 work Related 0 Neither syntactical nor run time overhead is in- curred when accessing persistent data. The Eumel/L3 model of virtual memory was strongly influenced by the Multics [Ben 721 ideas. Lo- Since data is persistent, the active instances oper- rie [Lor 771 introduced shadow paging for checkpoint- ating on the data should be persistent too; so we de- ing. A slightly more general variant of this method is cided that processes would also be persistent. In fact used in Eumel/L3 for both copying and checkpointing. this only requires that stack pointers, program coun- In 1979, most related work was yet to start (or not ters and other internal registers be regarded as data. yet widely known). Accent [Ras 811 and its successor Consequences of this decision are that: Mach [Acc 861 used copy on write techniques. These and various other systems (e.g. Amoeba [Mu1 841, 0 Program and system checkpoints are easy to im- Chorus [Gui 821, V [Che 841 and its predecessor Toth plement. [Che 791) are based on the message passing paradigm, but not on the persistence paradigm. 0 All running programs automatically become dae- The programming languages Elle [Alb 801 and PS- mons. Algol [Atk 821 already handled persistent and tran- sient data uniformly. To date, partial data persis- 0 For more complex functions (e.g. protection and tence (without dealing with faults) is part of the the synchronisation) active algorithms can be used in Comandos [Cah 931 project. Data and process per- place of conventional passive data structures. sistence including faults is also supported in Monads Thus tasks - consisting of an address space, one or [Ros 871 and by the KeyKOS [Har 851 nano-kernel, more threads, and a set of data objects mapped into first released in 1983. the address space - are principally persistent. The Eumel/LS concepts and experiences have also influenced the BirliX [Hir 921 operating system design Unfortunately not all tasks can be made persistent. at GMD. When beginning the L3 design we decided that all device drivers had to be user level tasks. This idea is natural, since there is nothing exceptional about a 3 Principles device driver, and it proved to be flexible and powerful. But, for hardware related reasons, most device drivers 3.1 Everything is persistent must not be swapped out, or even blocked for long enough to write back their status to the persistent We did not find any concept(ua1reason for anything store. So tasks can be declared to be resident, which not to be persistent. Obviously all things should live also means non persistent. as long as they are needed; and equally obviously turn- ing off the power should neither be connected with the 3.2 Processes are first class objects lifetime of a file nor with the lifetime of a local vari- able on a program stack. There are files that are only Most operating systems introduce passive data as needed for a few seconds, and programs that run for first class objects: they give unique identifiers or even weeks. path names t>othem, permit low level access control Some data (e.g. files) have to be persistent, so we etc. However, when processes are also persistent, this decided that all data should be persistent. The basic turns out to be upside down. An active process is more 3 general, flexible and powerful than a passive data ob- of inter-process communication. The integrity of mes ject (although the models are Turing-equivalent), es- sa.ge transfer, the uniqueness of task and thread iden- pecially when implementing objects with inherent ac- tifiers and one distinguished identifier are sufficient to tivity: e.g. traffic lights, floppy disk drives (turning solve these problems. The last item can be used as a off the motor if no request for 3 seconds) or a terminal root for higher level naming schemes. handler which cleans the screen and requests new au- Since all data objects are completely controlled by thorization (like xautoolog), when no keystroke occurs tasks, local identifiers are sufficient, unique only per for some minutes (or the terminal camera no longer task and not in time; this simplifies the kernel. Fur- “sees” the user). A simple example for this type of thermore higher levels gain flexibility, because they object is a clock which shows the actual time on the are less restricted by kernel concepts. Some naming screen and can be switched to different local times and binding mechanisms that have been implemented concurrently: on top of the kernel are described in section 5. PROC configurable screen clock : delay := 0 ; 4 Details do do This section gives a short overview of some details show (time + delay) ; of the support for persistence in Eumel and L3. More timeout := 60s - time niod 60s ; details are described in [EUM 79, EUM 79a, Bey 89, receive (client, msg, timeout) Lie 91, Lie 921. until msg received od ; delay := msg.time shift 4.1 Tasks, threads and communication od END PROC The L3-kernel is an abstract machine implementing the data type task. A task consists of This example also shows that Atkinson’s orig- inal scale of persistence [Atk 831 (transient, lo- at least one thread cal, own/global, .