KOSH Logical Architecture
Scribe: Jeff Grimmett (email@example.com)
Mailing List Summary
Week ending 13 DEC 98
Subjects under discussion
Feeble attempt to distill the various threads into major subcategories.
Glossary of Terms Bandied About
List of terms defined or used freely, and an approximate description of
what they mean, not necessarily correct.
List of external references used in the discussions of the week.
Subjects under discussion:
Lowest level of abstract services (HAL) supported by the hardare. Hardware
adds services to the BOSS which then presents them to the OS. BOSS is
thus more than a kernal, it is also an Object Request Broker.
BOSS thus allows for a similar type of dynamic object environment to HAVi
-- see URL in references.
Counterpoint was proposed that a more OO approach would be better, where
the OS consists of 'objects' (for example, a "sound" object) with known
requirements and attributes that a hardware designer can address. The
emphasis on this approach is to keep things as simple as possible, only
introducing complexity when absolutely needed.
Additionally, in such an object-oriented environment, hardware 'objects'
could be arranged in class tree structures; a 'family' structure trending
from more general (e.g. 'sound') towards the more specific (e.g.
'SOUNDMONGER PRO' audio card). One could talk to the "sound" object in a
general way (e.g. send a sound file to it) or talk to the
"sound/SOUNDMONGER" object directly. The advantage of talking to the
'sound' object is that it will (actually, SHOULD) know that the
SOUNDMONGER exists and thus will send the data in the correct format to
the card. On the other hand, the 'sound' object might determine that the
file being sent was more appropriate for the 'MUSICMONGER' card and send
it there instead.
Using this approach, one could possibly store drivers in a hierchial
Also see the "Object Sea" and "Registry" subjects
It is suggested that KOSH should implement this.
Memory / Object Access
Use of pointers as references to objects is probably not a good idea in a
true virtual object sea. Everything should be by reference. Reference
gives ownership, an extended degree of SW memory protection as well as
(This concept currently meets with great resistance from many fronts :-)
A counter proposal: The primary denizens of the object sea could be only
"Capital" objects (see Object Sea subject) which encapsulate smaller
objects such as lists, strings, etc. Pointers within capital objects are
allowed, pointers from within one capital object to WITHIN another
capital object are NOT allowed. When there is a legitimate need for one
capital object to know about another capital object or its contents, it
uses OS functions to do so safely.
Speed might be an issue here, so it is possible that Capital objects would
communicate directly with each other in a limited fashion (to limit the
possibility of violating the memory space of each object).
Related is the discussion of the Four Spaces: if a Capital object is
'trusted' enough, it might have need and means to bypass the memory space
integrity of another capital object.
An important question comes up: if KOSH is intended from the beginning to
be friendly to distributed processing environments, then passing data by
reference (pointers) is not possible -- the actual data must be passed
from processor to processor to be within its memory space. Or, possibly,
we design for speed (indirect referencing of data possible) at the lowest
level, and rely on system extensions at a higher level to allow the
addition of additional processors.
This came up as a sub-thread of the BOSS discussion. The term "Object Sea"
might imply to some that there is chaos rather than order in the
organization of the various objects that make up the BOSS and OS. However,
this does not have to be the case. One such proposal is for a series of
"chart objects" to make up the lowest level of the OS kernal itself. The
kernal would thus be built up of a series of objects, with a primal root
object class to get things started, and all the various functions of the
kernal (e.g. creation and removal of tasks, etc) being sub-classes of it.
An example of how powerful this could be is given. Consider if a new
task would normally be created using the system/kernal/task object.
However, suppose the developer needs more debugging information. If a
special debug subclass of the task class is provided, then the new class
could be created using a system/kernal/task/debugtask object.
Do we want to use the hierchial file structure for storing objects, or a
less rigidly organized semantic set? The advantage of the latter is that
it doesn't FORCE the hierchial view on the end user, but DOES allow it.
It's more than just a way of viewing the system, though. In a semantic set
structure, all objects in the sea offer thier services to all others,
similar to the Amiga library system in many ways. It is possible with the
hierchial structure that objects will become too overburdened handling the
traffic up and down the 'chain'.
Some caution is probably warranted, though. If every string, list, or
integer in use is in fact an object in the object sea, and thus
known to all other objects, things will very likely crawl. The term
"Capital object" came up to describe the primary denizens of the sea; it
is assumed that the minor objects mentioned above would be 'passengers'
of these Capital Objects (keeping with the nautical terminology).
Also, a hierchial structure imposes dependencies; the child class depends
on the parent class to pass it data of a certain type. Change the parent
class in such a way as to change that data, and the child class must
likewise be revised.
Or, whether to use one or not. It is possible in the object sea for
parent objects to 'know' what kinds of data are appropriate for them or
thier children objects, thus eliminating the need for a registry. Thus,
the 'sound' object, upon receiving an audio stream, sends it to the
SOUNDMONGER object. OTOH, upon receiving a MIDI score, it might determine
that none of its children can handle it and thus not pass it on.
Space, the final frontier
At least four realms of 'protection' are needed for the object sea to work
properly; System, Object, Shared, and Local.
System space is where the low level stuff works: kernal tasks, driver
objects, system objects, etc. System space can 'see' all other spaces, and
no others can access system space directly. Errors in system space
probably result in a system crash.
Object space is for trusted objects not as critical as system objects.
Objects in this space can see most of the OS, but cannot access the
system space. Kernal objects in system space can allow themselves to be
seen by object space (e.g. for messages to be passed).
Global space is intended for threads to communicate quickly with each
other. Object space objects can permit themselves to be seen in global
space for message passing. Plug-in object classes would live in this
space, as well as certain un-trusted that need to be regionally shared.
Local space is where application objects live, similar to what is seen in
Unix and similar OSs.
Glossary of Terms Bandied About
Basic Operating System Services
Primary denizens of the Object Sea. Smaller, 'local' objects that do not
need to be known to all other objects in the sea are encapsulated within
the memory space of the capital objects.
A 'template' from which objects are created. It defines a collection of
data and code, or rather how it is organized and how it behaves. An object
is created using this template, but the data structures are "filled" at
time of creation. One class can thus be the progenitor of many identical
Hardware Abstraction Layer. BOSS is the proposed HAL for KOSH.
An instance of a Class. The Class defines the structure and behavior of
objects created from it. The object itself fills out the structures with
actual data and performs tasks as needed.
A collection of object and class descriptions.
More or less, a class tree for a collection of objects, such as those in
the proposed object-oriented BOSS. Amiga's MUI class hierchy is an
existing example of one sort of "sea" of objects.
Object Request Broker
Used in this context, a memory pointer is a variable that points to the
location in memory of some data. This is also known as indirect
A term used to describe a database of information that indicates a number
of things to the OS. Most common use is to 'register' programs to the OS
so that it is aware that the programs exist, and what sort of data they
can handle. Windows95 uses a registry for such things; the Amiga does not.
Super-secret audio card made exclusively for KOSH by BLAZEMONGER, INC.
HAVi (Download the acrobat spec. While 200 pages in size, the first 40 are
Object-oriented kernal: here and here.