Moose specs: Revision 0!

[Gary D. Duzan]

   Ok, before going into the specifics, I just want to make a general
comment or two. First of all, there is no mention of a mechanism for
interprocess communication (or, if you prefer, object invocation,)
scheduling, and control. Personally, I prefer a blocking RPC with
lightweight processes (objects.) We should probably have some sort of
shepherd objects to manage groups of objects (like Unix signals.) All
objects should inheirit a set of control methods with default
functions, and the shepherd should have access to them. We also need to
specify some security mechanism  to restrict access to object methods.

=>                     Moose Operating System
=>                     Initial Specifications
=>                       Revision 0, 2/8/93

   We gotta get rid of that name. Dennis seemed to like my suggestion
of 'Midgard', in honor of the mythical serpent that encircled the
Earth.

=>     For example, a program which creates a graphical screen
=>display would be able to use the same code to generate a printout
=>or send a fax just by referencing a different device object.  On
=>the other hand, complex devices could also be given more elaborate
=>interfaces to allow maximum efficiency in accessing hardware.  A
=>certain amount of universal portability might be lost in this case,
=>but the application programmer would be left to choose the
=>appropriate method to meet his or her needs.

   This is a tall order, but ultimately the ideal case. It will take
some very careful and exhaustive design work to pull it off.

=>     As applications grow more and more complex, software designers
=>argue that they require additional resources to support their
=>needs.  Most graphical user interfaces, for example, are quite
=>complicated and require considerable effort on the part of the
=>application programmer to develop software for.  In many ways
=>modern applications do require more resources, but these could be
=>reused and shared among similar applications, significantly
=>reducing the total overhead involved.

   This brings up the question of the general user interface. Do we
support a character-mode interface? I believe that a GUI (graphical
shell) should present object methods to the user, so if we do implement
a character-mode shell, it should have a syntax to reflect the object
method invocation semantics.
   As for the graphics primitives, we should probably start from those
provided by existing graphics accelerator hardware as a minimal set.
The video driver should provide these services and advertise any
additional ones that it can do fast.  However, any objects that use the
additional services should be ready to ignore or emulate (from the
minimal set) them in case the video driver doesn't provide them.

=>                                         The kernel will be divided
=>into the following logical sections: 
=>
=>          General Memory Management
=>          Shared Memory Management
=>          Device Memory Management
=>          Memory Transfer (DMA)
=>          System Clock
            Object Method Invocation/Interprocess Communication

   This might be doable at the device driver level, but it might be
better to put it in the kernel so it can take advantage of hardware-
specific optimizations (e.g. remapping, a la Mach.) It will be an
interesting task to come up with a method that translates well to
different hardware.

=>1. Files
=>
=>>> Anybody have ideas on how files can be implemented as persistent
=>>> objects?  How about memory mapped I/O?

   If page faults and page flush calls can be rerouted to a shepherd
object, it can translate them into file system operations (along
with an allocate/free page call.) This could take care of both (since
they can be viewed as the same thing, anyway.)

=>E. Filesystem Devices

   Operating Systems researchers have gone nuts in creating new
file systems. There should be more than enough to choose from.

=>F. Data Link Devices
=>G. Network Devices
=>H. Transport and Session Devices

   Do we want to provide intra-machine drivers for these? Should
they be a standard IPC mechanism?

   So what language do we write the high-level stuff in? Should it
matter? Can we make it not matter?

   If any of this makes any sense, it is most likely some strange
accident.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts