Stella Module and Context Structure

 

The structure of a Stella system is highly pragmatic. There are three aspects of the structure that have a major influence on the flexibility, the efficiency and the robustness.

  1. The module and context structures.
  2. The module and entity linkage.
  3. The privilege structure.

Stella Core Module and Entity Structure

A Stella system does not have a large kernel, a small kernel, a microkernel or even a nanokernel. Stella is a modular operating system where the functions are finely divided into modules linked directly together as they are "loaded" or "initialised". Even a "minimum" Stella system is likely to incorporate about a dozen such modules. A full system may have as many as a hundred modules, each with a well-defined function and, more importantly, well-defined interactions with other modules.

Stella "core modules" form the core of a Stella system. These core modules provide the basic facilities of the operating system: the management of common resources and communications within the system.

All other facilities, whether they are considered to be extensions to the operating system, utilities, drivers or applications are provided by "entities".

The distinction between these two levels is related to the old barber paradox: in the town where all men are shaved by the barber and no man shaves himself, the barber has to be a special case. Because entities can be freely created, replaced or removed, the management of these entities cannot be entrusted to another entity.

An entity is merely something (data, code, context or a combination of the these) that is known to and identifiable by the operating system.

In this diagram, the modules become increasing specific to an individual system (hardware environment or applications) as you move up through the levels. The highest level of flexibility is required at the highest level.

With the exception of the bootloader, all Stella modules have a uniform structure. A module comprises code and initialised data. The module starts with a header that defines the facilities required by and provided by the module and any initialisation that is required.

A complete system is built simply by concatenating the modules required - the bootloader ensures that all the modules are linked as they are loaded.

Stella core modules

At the core level, the flexibility of Stella comes from the ability to pick a combination of operating system modules to meet individual requirements.

While it is, in principle, possible to change the core modules in a live system, this process is subject to such restrictions that it not currently supported.

Stella entities

An entity is a distinct unit recognised by the operating system. A basic entity is no more than a block of memory used to link the entity's data, code and properties.

Entities can own or use other entities. The operating system keeps a record of all the other entities that are owned by a given entity and all the other entities that are using a given entity. These twin "ownership" and "usership" properties are the keys to the dynamic reconfiguration of applications and operating system extensions that give Stella its flexibility.

An entity in the form of a "job", executing under control of the scheduler, requires a job context. The job context is the data area, within the entity, used by the task manager. In the most streamlined versions of Stella, the job context is no more than a save area for the registers (saved while it is not executing) and its status (priority accumulator, timers, events, etc.). In "heavier" versions of Stella, the job context is extended to include save areas for the other hardware facilities (floating point units, memory management units, etc.).

Transient tasks, such as external event handlers, do not require an extended context.

Type of entity Working data Fixed data Code Job context
Shared or common data Yes Maybe    
Protocol definition   Yes    
Protocol handler Yes   Yes  
IO device driver Maybe Maybe Yes  
IO channel Yes      
External event handler Yes Maybe Yes  
Utility   Maybe Yes  
Job Maybe Maybe Maybe Yes
The "contents" of various types of entity

Entities themselves can be created in two different ways.

  1. The code and initialised data for the entity can be embedded in a module. This module may be added to the operating system so that the entity is created during initialisation. Alternatively, the module may be "loaded" at any time while the system is live.
  2. Entities can also be created "at run-time" by any application. This is particularly useful for entities that are used for managing common data or for jobs that do not have any code of their own.

Stella context structure

In virtual machine operating systems (such as UNIX) the context within which the code of a program unit executes is simply its virtual machine. The context is an encapsulated bundle of code, data, and properties such as access rights, memory map, execution priorities etc. In born-again UNIX terminology, this is a heavyweight context. Attempts to mitigate the extreme rigidity of this approach have led to two main bodges to the virtual machine structure: threads and objects.

The purpose of a thread is to allow more than one task to share a "heavyweight" context and thus break the one to one to one relationship between programs, tasks, and contexts.

The purpose of an object is to provide a reduced encapsulation that excludes the execution properties of a task. This means that several objects, each with its own context, can be used within a single task, providing a level of modularity and structure within otherwise amorphous program environments.

Threads and objects are two very small steps in the direction of Stella. In Stella, each entity has its own context. Indeed, an entity could be considered to be the physical representation of a context. Rather than an arbitrary collection of heavyweight contexts (processes), lightweight contexts (threads), and taskless contexts (objects), in Stella any context may have any combination of code, data and properties.

Context sharing

Contexts may be shared implicitly (by ownership) or explicitly (by usership). Entity ownership trees create an automatic right to share contexts. Each owned entity can share the contexts of its direct and indirect owners. The simplest example is that of job ownership trees.

In this illustration of a simple job structure, job 1 has a context independent of all other jobs. Job 31, however, is owned by job 3 and, therefore, automatically has the right to use job 3's context as well as its own. Likewise, both job 21 and job 22 are owned by job 2 and can use job 2's context as well as their own. Job 21 and job 22, however, cannot use each other's context (unless they request permission by registering as "users").

Unlike processes and threads, the ownership concept of context sharing is recursive. Thus job 221 and job 222 are independent of each other, but both have the right to use the context of job 22 and job 2.

This job structure allows co-operative jobs to share data and code within the context of a common owner. Job 221 and job 222 do not need any code or data of their own, they can use the code and data belonging to job 2 or job 22.

It might seem odd that only the bottom jobs of a tree have complete privacy, but this is a natural consequence of the Stella self cleaning entity management. When an entity is removed, all the entities that it owns are also removed. As entities that it owns are the only entities with an automatic right to share its context, all other entities with an automatic right to share its context are automatically removed.

Composite contexts

Entities can also use facilities in unrelated entities. Depending on the structure of these entities, this usage can be analogous to the use of shared objects, private objects, or dynamic link libraries in other operating systems.

"Incomplete" contexts can be combined permanently or temporarily to produce complete contexts. For example, an operation to read some data from a file requires the device driver to be able to access the calling job's context (the destination of the data) as well as contexts internal to the filing system (the source of the data and the transfer mechanisms). All these contexts, except the operating system, are defined by entities.

Each context in this example has a good reason to be separate.

In a working system, there will be many contexts at each level. For an operation via a particular channel, a particular combination of contexts is required.

The freedom with which contexts can be combined in Stella provides the simplicity of system design that is one of the fundamental bases for its unparalleled accessibility.  

  Back to table of contents.


Copyright (c) 1997 Tony Tebby.