next up previous
Next: Previous work Up: adeos Previous: adeos

Introduction

Operating systems were born out of a desire to encompass system libraries and hardware abstraction software in order to offer users with a standardized application programming interface. In time, operating systems came to automate the sharing of hardware resources amongst multiple user programs. Hence, users no longer had control or direct access to the hardware they use. This has its advantages as it becomes possible to write portable programs and force users to abide by some rules imposed by the operating system administrators. On the other hand, all hardware accesses being channelled through the operating system, programmers became trapped in the operating system for which they programmed. In turn, users became trapped in the operating system they chose and could not use applications developed for other operating systems.

As many different and incompatible operating systems, both source-wise and binary- wise, became adopted, the gap between the programmers and users of one OS and the programmers and users of another OS became wider and wider. The propagation of computerized systems in different specialty fields did nothing to alleviate this divide. In the current state of the OS field this is somewhat unfortunate as there are often cases where the functionalities or applications of a given OS may be very useful to the users of another OS, but these users may not profit from such capabilities as the OS they use has not been designed to share its resources. The same can be said about system developers as they have no way to control the hardware outside of the capabilities provided by the running OS. Although this level of control may be desirable for debugging and performance measurement.

Current solutions to provide such a capability rely heavily on simulation or on limited-simulation supported by run-time mechanisms. Hence, the simulated OS has no direct access to the hardware and is treated as hostile by the simulator which, itself, runs on top of another operating system. This stacking of OSes becomes rapidly inefficient and limited. Other solutions attempt to build a miniature OS on top of which other OSes may come to be implemented and offer user capabilities. This, though, is not a practical approach as most users and programmers don't want new OSes, they simply want their current ones to interact more seamlessly.

What is desirable is to have an equal and trusted status among already existing OSes that use the same hardware in order to give control back to the application programmers and system administrators.

In section 2, previous work is presented and discussed. Section 3 covers the architectural concepts behind Adeos. Section 4 discusses the implementation details of Adeos on the ix86 using Linux as a host to startup the hardware. Section 5 discusses example applications of Adeos.


next up previous
Next: Previous work Up: adeos Previous: adeos
root 2001-02-15