General purpose multimedia computing platforms should endow text, images, audio and video with equal status: interpreting an audio or video stream should not be a privileged task of special functions provided by the operating system, but one of ordinary user programs. Support for such processing on a platform on which other user applications are running, some of which may also be processing continuous media, cannot be achieved using existing operating systems -- it requires mechanisms that will consistently share out resources in a manner determined by both application requirements and user preferences.
Continuous media streams have two important properties. The first property is that their fidelity is often dependent upon the timeliness with which they are presented. This temporal property of continuous media imposes the requirement that code which manipulates the media data may need to be scheduled within suitable windows of time. The second property is that they are often tolerant of the loss of some of their information content, particularly if it is known how the data is to be used (e.g. many compression schemes rely on human factors to achieve high compression rates). This informational property, without regards to its exact nature, may be exploited by systems which handle continuous media.
The properties of the streams can be extended to the applications which process them; we have temporal requirements for such applications which are stronger than traditional data processing applications, and informational requirements which are weaker.
In order for an operating system to support both traditional and multimedia applications, a wider range of facilities than is found in current operating systems needs to be provided. This paper describes an operating system, called Nemesis, whose goal is to provide this range of facilities. This work was carried out as part of the Pegasus project[1], an ESPRIT Basic Research Activity.
The underlying assumptions made in the Pegasus project are:
In multimedia systems which capture, display, and store continuous media the range of applications is constrained (although by no means currently exhausted). The introduction of the processing of continuous media in real time adds an important new dimension. If the current situation is typified as using processors to control continuous media, future systems will be typified as systems in which the data types operated on have been extended to include continuous media streams[2]. What we are concerned with here is to provide an environment in which such applications can be developed and run.
Traditional general purpose operating systems support the notion of a virtual processor interface in which each application sees its own virtual processor - this provides a method for sharing the real processor. However, each virtual processor sees a performance which is influenced by the load on the other virtual processors, and mechanisms to control this interference are generally not available. Multimedia applications require such mechanisms.
One way of controlling this interference is by providing multiple real processors. For example, many multimedia applications (or parts thereof), run on processors on peripheral cards so that the main processor is not involved. Moreover, the code running on the peripheral is likely to be embedded and there is no danger of competing applications using the peripheral at the same time. The same approach is also used in mainframes where the use of channel processors reduces the I/O demands on the central processors, in particular ensuring that the central processors do not get overloaded by I/O interrupts.
Our aim in Nemesis is to allow a general purpose processor to be used to provide the functions one would find in a specialised DSP peripheral while providing the same control of interference across virtual processors as can be achieved with distinct hardware. We wish to retain the flexibility of the virtual processor system so that resources can be used more efficiently than in a dedicated-peripheral approach.
In approaching the design of an operating system with these goals, the immediate question of revolution versus evolution arises. Should one attempt to migrate a current operating system (or indeed use a current operating system) in order to meet these goals, or should one start afresh? The reasons why current general purpose operating systems are not appropriate are well established. Similarly, hard real time solutions which require static analysis are not appropriate in a situation where the application mix is dynamic.
General purpose operating systems with ``real time threads'' in which the real time behaviour is provided by static priority are also inappropriate, unless one is running a single multimedia application or can afford to perform an analysis of the complete system in order to assign priorities. A better solution might be to take an existing operating system and modify its scheduling system to support multimedia applications - perhaps one reason for the difficulty in performing such a scheduler transplant is that knowledge of the characteristics of the scheduler often migrates to other components making the effect of replacement unpredictable.
This, together with our view that processor scheduling is not the only important aspect of operating system support for multimedia applications has lead us to start from scratch. As we describe below, providing a realisation of a virtual processor that has the properties that we require has profound implications on the complete structure of the operating system.
The main theme guiding the design of Nemesis is multiplexing system resources at the lowest level - in the case of the processor, this multiplexing system is the scheduling algorithm. However, it is the multiplexing of all resources, real or virtual, which has determined the fundamental structure of Nemesis.
This has given rise to a system in which as much functionality as
possible executes in the domain of the application
. This includes code that in a
traditional microkernel would execute in a shared server. It should be
emphasised that this need not change the interface seen by application
programmers. The API seen by a programmer is often a thin layer of
library code supplying a veneer over a set of kernel traps and
messages to server processes - whereas in Nemesis the majority of the
functionality would be provided by a shared library. As an example, a
POSIX API in a Nemesis domain can be provided over a POSIX emulation
which mostly runs within the applications domain.
In Nemesis a service is provided as far as possible by shared library code and the design of a service will aim to minimise the number of changes in protection domain. To aid in the construction of such services, references between the various parts of the code and data are simplified by the use of a single address space with protection between domains provided by the access control fields of address translations.
After a discussion of quality of service management and application crosstalk in section ii, the structure of the Nemesis kernel, the virtual processor model and the event mechanism, is described in detail in section iii. Events are a native concept in Nemesis. Events can be used to support an implementation of event counts and sequencers, and in practice all domains currently use this mapping. Other synchronisation primitives can be built on top of event counts and sequencers when required.
Scheduling amongst and within domains is described in section iv. Two domain scheduling algorithms are presented, one in detail, one briefly. Although scheduling is an important aspect of supporting multimedia applications, Nemesis does not take the view that there is a correct scheduling algorithm; indeed the structure of Nemesis is designed to make the use of alternative scheduling algorithms straightforward.
Two aspects of the system are only briefly described: the linkage model for the single address space and the interdomain communication mechanisms. A system in which code implementing operating system services executes within the application domain gives rise to problems of linking the pieces of code and data required and of providing safe and efficient sharing of this code and data. These problems, as well as those directly attributable to the use of a single address space, are discussed in section v.
Higher layer inter-domain communication (IDC) systems can be built over events. Section vi presents the system used for interdomain invocations based on an RPC model. This section also presents the bulk transfer mechanism used in Nemesis, in the context of support for networking I/O.
The current state of the implementation and systems built over it are described along with some early conclusions in section vii.