UniOS: The Proposed Final Layouts

UniOS has come very far in the last few months, and because of this, we may be on the verge of deciding on the final OS layouts for the project.  This does not cover the specifics of how it will be implemented.  It is more of a "big picture" of how the OS will work.  The other OS layout documents found in the UniOS page, which are outdated, or not currently being considered are: Kite Model, Object Abstract, and Object "No Kernel" System. This document is, however, based on ideas found within those models. If you find something confusing here, it's most likely because I explained it elsewhere.  If either of these become the final, then I will post a very large explanation of it.

As a group, we have mostly agreed on the fact that we want a Multiuser, Multitasking, Hardware Abstracted, Object Oriented Hierarchy system.  So both of the potential final models reflect this philosophy.

First, some diagram explanation:

Lines:
Black = Physical Communication Channel 
Pink = Object Communication Channel

Box Colors: 
Red = Physical World 
Orange = Platform dependent implementation
Yellow = Platform independent implementation
Green = Processes and Applications (platform dependent after compiled)

These two proposed layouts are the culmination of the major ideas being expressed in the UniOS mailing list.  I will explain both ideas here: 

UniOS Final OS Layout Proposal: A

The first idea is a "minimal function set" pluggable kernel based OS, in which you have the memory management, Inter-process communication, multitasking, and protection in a microkernel-like form.  The rest of the OS is a hardware abstracted, object hierarchy.  Each object can interact with every other object via the kernel IPC.  All object communicate with hardware via the high level hardware abstracts or low level device driver objects.  The hardware abstracts map to the low level device driver objects, which run outside of the kernel space (see Microkernel).

Diagram:

Main advantage over "B": Speed
 

UniOS Final OS Layout Proposal: B

The second idea is a "no kernel" system.  It is essentially exactly the same as "A" but the kernel related functions listed above are implemented as an object (probably the "system" hardware abstract).  We, as a group believe it is slower, but more flexible.

Diagram:

Main Advantage over "A": Flexibility

If both of these designs is accepted as a final candidates, we will hold a vote to see which to develop (or possibly a way to incorporate both).