-- Nucleus.notes
-- last edited by Levin on Fri, 6 May 83 14:56 PDT

Proposed configuration structure of Cedar:

BasicHeads

MesaRuntime

Nucleus
  Tentacles
    BootStartList
    LoadState
      LoadStateFormat
    DebuggerSwap
      CPSwapDefs
      DebuggerSwap
      Runtime [CallDebugger, Interrupt]
      RuntimeInternal [WorryCallDebugger]
    GermSwap
      Boot
      BootSwap
      Runtime [GetBuildTime]
  Disk
  VM
  CedarRuntime ( = SafeStorage; Rigging; Lists; Atoms; Reals)
  File
  Checkpoint
  Time replacement (= Tempus + DateAndTime)
  BasicIO
  Loader

TerminalDriver (replaces UserTerminalDriver and TerminalMultiplex)

Network
  Communication
  Pup
  GrapevineUser
  RPCRuntime
  UserCredentials
  DirectorySystem (includes STP)

Installer (drives initialization sequence)

AbstractMachine
  AMTypes
  AMProcess
  AMEvents
  AMModel
  RestOfIO
  Bugbane

UserInterface (similar to present CedarUserInterface)

  
Notes on Initialization sequence:

The Germ transfers control to a "wart" module in Installer, which then carefully invokes appropriate procedures in BasicHeads and MesaRuntime to get the Mesa machine.  This is approximately the same as the initial portion of PilotControl.  The Nucleus configuration is then started by invoking START InitSequence.NucleusInit, which is a null program module that triggers the control list for the Nucleus configuration.  (Control lists work because the MesaRuntime initialization ahs been done.)  Now the Cedar language facilities are available and the non-bootloaded portions of the boot file are usable.  The remaining configurations below the level of Installer (TerminalDriver and Network) also have control lists, but they are executed on demand by calls from Installer as it puts up the display, checks credentials, etc.

An alternative strategy would be to have uniform entries in InitSequence for BasicHeads, MesaRuntime, Nucleus, TerminalDriver, Network, AbstractMachine, UserInterface and to have Installer use these.  (It would have to be careful to use RuntimeBackdoor.Start[InitSequence.MesaRuntimeInit] instead of START InitSequence.MesaRuntimeInit in order to get the Mesa machine started, but otherwise everything is done uniformly.  This might make it easier to pare down things for the Dicentra.  The basic boot file has everything up to Installer.