The AdaOS Operating System (2000)

Overview: The AdaOS Operating System

Document Revision: 2 (September 2000)

Author: N. J. Roberts

AdaOS is a new operating system (OS) being developed by a small group of enthusiasts. The main purpose of this project is to demonstrate the use of the Ada programming language for system software of this kind.

The Internet base for this project is the AdaPower web (World Wide Web, WWW) site whose Universal Resource Locator (URL) is just below.

http://www.AdaOS.org

The intention is to release the OS free of cost to the general public, under the Free Software Foundation 's General Public License (GPL) or a licence of our own devising. This licence will allow the OS - in both directly usable and source code form - to be freely distributed, used, and even modified, by everybody; it will ensure that no-one can make legal claims which will end up restricting these freedoms for others.

Introduction

This web page presents an overview of the design for AdaOS so far. Be aware that there will, doubtless, be refinements to be made, and, indeed, the chances are some major changes will be required as well. Further pages will provide detailed design information.

Ideas, comments, and suggestions, by anyone and everyone, are welcome (send them tothe author, please). This includes the quality of the documentation (e.g. spelling, grammar, exposition, accuracy, and style) as well as the actual design. Remember, however, that this documention is at a relatively preliminary stage, and cannot be expected to have the polish of final documentation.

Design Objectives

My (the author's) original reasons for embarking on the development of this operating system were:

• because I wanted to write a free Ada compiler (different to those already available), and no existing freely available operating system seemed to offer all the capabilities that would nicely support the Ada language;
• existing freely available operating systems (nearly all based on UNIX) did not strike me as being (any longer) the acme of OS design;
• nothing could be quite so much fun as to have your very own design of OS to play with!

However, having researched the subject a little, it became clear to me that there were at least two good reasons for the development of this OS that went beyond these personal reasons:

• there is, to the best of my knowledge, no operating system which has been written in the Ada programming language, other than small real-time and run-time systems, and it would be a significant boost to the advocacy of Ada to be able to say "look, here is a full operating system written in Ada";
• apparently, no-one has yet made or modified an OS to fully comply with the European Computer Manufacturers Association 's Portable Common Tool Environment (PCTE), which started out as an ECMA standard (ECMA-149, the Ada language binding being ECMA-162), and which is now an ISO standard (ISO/IEC 13719).

Furthermore, research made it equally clear that there were certain new (highly inter-related) features that are likely to be demanded (indeed expected) of a modern operating system:

• a highly modular design , providing the isolation of different parts of the system's software from each other, facilitating better security provision, fault isolation, support of software engineering principles (good software design, essentially) and the software development and management process, and customer choice (where there is a market);
• a fully distributed design, where the computers (workstations) connected within a local area network (LAN) can be easily configured to behave as a single unified system, from any ordinary user's point of view (as if the workstations were simply the terminals of a traditional centralised mini or mainframe computer system);
• an inter-process communication (IPC) system which provides totally seamless communication between processes on different workstations within the LAN, whilst at the same time providing highly efficient communication between processes on the same workstation, so supporting the increasingly popular remote procedure call (RPC) style of distributed client-server programming, as well as an object-oriented system organisation;
• much better security facilities, plainly of importance to any military organisation, but also of great importance to most commercial and private users (and it is a particular military requirement that the security-critical parts of the OS be separated, as far as reasonably possible, from all other software, something that a modular design helps to facilitate);
• adherence to the many standards , both formal and informal, now in existence pertaining to the design of operating systems;
• increased reliability ;
• efficiency , in terms of speed and use of resources.

So, the current specific design objectives of AdaOS can be summarised as follows:

• (mostly) written in Ada , with emphasis on good design and solid implementation;
• modular design (without overly compromising performance);
• an efficient IPC mechanism;
• fully distributed networking support;
• distributed client-server support;
• an object management system that works in accordance with the Object Management Group 's Common Object Request Broker Architecture (CORBA);
• compliance with PCTE , which includes security features that comply with the US Department of Defense National Computer Security Center's Trusted Computer System Evaluation Criteria (NCSC TCSEC, generally called the 'Orange Book').

Components of the Operating System

The software making up the AdaOS operating system, even at the lowest levels of system software, is composed of a relatively large number of relatively small parts, which can be called components (although this terminology is neither a generally accepted, nor a particularly important, formalism in computer science or industry).

Each component is intended to be a separate program , executing independently as a separate process , which has its own separate address space, and is isolated from all other processes except for a carefully controlled IPC mechanism (see 'The Kernel' below).

Version Nomenclature

Initially, AdaOS will be targeted to IBM-compatible Personal Computers (PCs) with 32-bit Intel Architecture (IA-32) compatible processors, these being the commonest variety of computer. AdaOS for this target will be designated AdaOS (PC/IA-32) .

The first fully working, but minimal, version of AdaOS (PC/IA-32) will be designated as AdaOS (PC/IA-32) V1 . Releases will be designated AdaOS (PC/IA-32) V1 Rn , where n starts at 1 and increments.

Thus, the full title of any component 'X' of AdaOS (PC/IA-32) will be 'AdaOS (PC/IA-32) X', and the first version of the component will be 'AdaOS (PC/IA-32) X V1'. Releases will be 'AdaOS (PC/IA-32) X V1 Rn'. Throughout the AdaOS documentation, these will be abbreviated to 'X' and 'X V1' respectively.

Versions of AdaOS for other processor and computer architectures are planned for the future.

Component Names

Many of the components are of a nature that (for the sake of efficiency or simplicity) they introduce an aspect of policy , as well as a mechanism for doing something. This means that there will likely be a necessity to develop alternative versions with different policies. Of course, sometimes there will sometimes be a necessity to develop an alternative version of a program in order to introduce a more efficient mechanism, or to accommodate an alternative overall design of the operating system. Part of the beauty of a modular design is that such changes are relatively easy to make.

Each component has a full 'title', and also a (generally more compact) 'name', which is the name of the directory (or object) that will be used to contain things relevant to that component.

Some of the more important components are listed below. The title is given first, and then the name in square brackets. The components are divided into three sections: trusted, controlled, and 'toolbox'.

Trusted Components

The trusted components are the ones which either adminiser security themselves, or upon which at least one other trusted component depends. As the classification suggests, these components form an elite, since any failure of any trusted component could, in theory, compromise the security of the entire system (in reality, of course, this will be true of some trusted components more than others).

Collectively, the trusted components of a system make up its Trusted Computing Base (TCB).

For this reason, the Orange Book advocates that the TCB be reduced to a minimum, so as to make it as practical as possible to subject all the trusted components to special scrutiny and software-engineering techniques and conditions, and so that it can be kept specially secret where necessary.

The necessity for a solidly designed and implemented set of interfaces between the TCB and all other software ('controlled' software) is also clear. There is an especial requirement for all these interfaces to be impervious to faulty input data.

• Boot Programs [boot]
• Kernel [kernel] ;
• Device Drivers [drivers] ;
• Local Storage Manager 'Aquila' [aquila] ;
• Network Router [router] ;
• Network RTC Synchroniser [rtc_sync] ;
• Distributed Storage Manager 'Cortex' [cortex] ;
• Distributed ORB & Process Relocator 'Avarus' [avarus] ;
• Virtual Graphics Console [vgc] ;
• User Identity Authenticator [uia] .

Controlled Software

All software which is not trusted (within the TCB) is controlled software . All the security controls provided by the TCB can be brought to bear on the controlled software. If this is done diligently, and there is no flaw in the TCB, no controlled component can under any circumstances subvert the security of the system, whether deliberately or accidentally.

Nevertheless, components will, in general have to trust the operation of the other components they call upon during their execution. There will be some controlled components which are called upon a great deal, and so these may be considered 'semi-trusted'.

All the components listed here are controlled, but will be depended on so much that they must be 'semi-trusted'.

• Hierarchical Namesystem Manager 'Carrot' [carrot] ;
• Transaction Manager [tran_man] ;
• Windowing Executive;
• Windowing Stylist;
• various foreign filesystem managers;
• Database Core;
• Print Manager;
• Fax Manager;
• Voicemail Manager;
• IP Manager;
• System Object Browser;
• User and Security Management Tool;
• Workstation Boot Management Tool;
• Network Health and Configuration Tool;
• Backup and Archival Management Tool;
• Application Executive System 'AXS';
• a 'friendly' text editor [FrEd].

'Toolbox' Programs

These are the programs we will have to implement first, on a suitable host operating system (such as Linux/GNU, for example), in order to build up a first viable implementation of AdaOS.

Having achieved that, these tools will be ported to AdaOS, for further development efforts.

• IA Assembler;
• Ada Compiler;
• OMG (CORBA) IDL to Ada Translator;
• SQL Module Compiler.

I've not explicitly mentioned test programs. There will be many test programs (whole suites of them, in some cases) for each component.

At present (August 2000) the lists presented above will be very much incomplete. There will be many more components required to build even a rudimentary working system. Eventually, of course, the number of components will run into the hundreds or thousands.

You will see that, as well as the actual implementation of these components, the documentation for the AdaOS project is also on ongoing process, including this overview and the individual component overviews it links to.

02/09/00 20:48:22 NJR HOME