GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien164
                           CMOS SYSTEM OVERVIEW
                 Jerry Stern, Greg Ruth, and Jack Haverty
                       Bolt Beranek and Newman Inc.
                             January 12, 1981
     Stern, Ruth, and Haverty       -1-                    Version 1.0
     IEN 164                   January 1981               Preliminary
                             Table of Contents
     1   Introduction.......................................... 2
     2   General Design Considerations......................... 3
     3   Process Management.................................... 5
     4   Interprocess Communication............................ 5
     5   Input/Output.......................................... 6
     6   Memory Allocation..................................... 7
     7   System Clock.......................................... 8
     8   Software Development Tools............................ 8
     9   Future Development.................................... 8
     10   CMOS System Calls.................................... 9
     11   System Generation................................... 19
     Stern, Ruth, and Haverty       -i-                    Version 1.0
     IEN 164                   January 1981               Preliminary
     1  Introduction
          CMOS is a multiprogrammed  real-time  operating  system  for
     BBN's  C-machines.   It is essentially a reimplementation of MOS,
     (1) a PDP-11 operating system developed by SRI.  Whereas  MOS  is
     written in Macro-11 assembly language, CMOS is written in C.  (2)
          Programming  support  for  CMOS  is  provided  by  the  UNIX
     operating  system.   CMOS  itself,  as  well  as  program modules
     written to run as CMOS processes, are edited and compiled on  the
     UNIX  operating  system,  and  object modules are loaded into the
     target machine.  Since both the development and  target  machines
     support  C-based  code,  it  is  also feasible to do some initial
     debugging in the time-shared environment.
          CMOS is a small, simple operating system that  provides  the
     following basic features:
  1. multiple processes
  1. interprocess communication/coordination
  1. asynchronous I/O
  1. memory allocation
  1. system clock management.
          CMOS development was motivated by the desire  to  produce  a
     C-machine  operating  system  suitable for use in communications-
     oriented applications.  In light  of  favorable  experience  with
     MOS,  it was decided to adapt a version of MOS for the C-machine.
     The choice of C as a system programming language was dictated  by
     the  specific  nature  of  the  C-machine.   The  C-machine  is a
     microprogrammed,  20-bit  machine  which  has   an   architecture
     explicitly  designed  to  support  the C language.  The C-machine
     comes in two models:  the C/50, which has a 1-megabyte (1  "byte"
     =  10  bits) physical address space and no memory management; and
     the C/70,  which  has  a  2-megabyte  address  space  and  memory
     management.   Versions  of  CMOS  have been developed for both of
     these machines, as well as for the LSI-11 and the Z8000.
     _______________
     (1) Kunzelman, R. C.,  J. E. Mathis,  and  D. L. Retz,  "Progress
     Report  on Packet Radio Experimental Network, Quarterly Technical
     Report No. 8."
     (2)  Kernighan,  B.  W.  and  D.  M.  Ritchie, "The C Programming
     Language", Prentice-Hall, Inc., 1978.
     Stern, Ruth, and Haverty       -2-                    Version 1.0
     IEN 164                   January 1981               Preliminary
          It should be noted that, although CMOS is targeted  for  use
     in  several  applications,  it has not yet been used anywhere and
     should be considered as still under development.
          One major motivation for the creation of CMOS was to provide
     an  operating  system for the C machines, for use in applications
     where the memory limitations make LSI-11  approaches  unsuitable.
     Although  CMOS  will run on LSI-11s, this is not an intended use.
     CMOS systems may use processes which exceed the address space  of
     the  LSI-11  architecture,  and  can only be run on C-machines or
     other machines which support the needed memory.
          The important aspects of the CMOS design  are  described  in
     the  following  sections.   The final sections provide a detailed
     description of CMOS  primitives  and  general  system  generation
     information.
     2  General Design Considerations
          The design and programming of CMOS have  been  motivated  by
     goals  of style, clarity, and consistency rather than a desire to
     achieve ultimate efficiency.  This is not to say that  efficiency
     issues have been ignored.  CMOS is quite compact and efficient by
     virtue of its  simplicity.   Design  principles  and  programming
     practices  have  not  been  compromised, however, for the sake of
     saving every possible byte or cpu cycle.
          CMOS is designed to be an  "open"  operating  system.   This
     means  that  no  distinct  division  exists between the operating
     system and the application program.  One can view  the  operating
     system as a collection of library routines.  The operating system
     can be easily extended by adding new routines and can be  reduced
     by  excluding  unneeded routines.  The programmer is not confined
     to the outermost interface presented by the operating system.  If
     appropriate,  the  programmer  can  directly  access  lower-level
     interfaces.
          Although CMOS is intended primarily for  C-machines,  it  is
     designed  to  be a portable operating system.  The use of a high-
     level language is,  of  course,  the  principal  factor  in  CMOS
     portability.   Small  size  and  simplicity  are  other important
     factors.  The design attempts to minimize the amount of  machine-
     dependent  code  and  to segregate it into separate modules.  The
     I/O system design allows for easy replacement of device-dependent
     modules.   Versions  of  CMOS  exist for the PDP-11 and the Z8000
     computers.
     Stern, Ruth, and Haverty       -3-                    Version 1.0
     IEN 164                   January 1981               Preliminary
          CMOS does not  support  either  virtual  memory  or  virtual
     address  spaces.   The  entire  system  shares a single, physical
     address space.  This lack of  sophistication  is  due,  in  large
     part, to the nature of real-time systems.  Programs and data must
     be continuously  available  in  main  memory  in  order  to  meet
     response-time requirements.  Thus, virtual memory techniques such
     as  swapping  or  paging   are   not   suitable   for   real-time
     applications.
          The issue of virtual address  spaces  is  more  complicated.
     The  most  common  reason for providing virtual address spaces in
     real-time systems is to overcome an architectural  deficiency  of
     the  computer.  Many computers have small address spaces, yet can
     support a much larger  amount  of  physical  memory.   Therefore,
     multiple  address spaces are required to take advantage of larger
     memory sizes.
          The C-machines do not suffer from this architectural defect.
     The C/50 provides a one-megabyte address space and the C/70 twice
     that.  This is  sufficient  for  all  currently  envisioned  CMOS
     applications.   For  this reason, the current CMOS does not need,
     and does not support, virtual address spaces.  For other machines
     (e.g.,  the  PDP-11),  address space limitations are more severe.
     On these machines, CMOS may be limited  to  a  class  of  smaller
     applications.
          Other applications may motivate further extensions to  CMOS,
     to  introduce  process  isolation  using  memory mapping, dynamic
     process creation, preemption, or other  additions  to  the  basic
     functionality.
          The use  of  a  single  address  space  gives  CMOS  several
     important advantages over multiple address space systems.  First,
     the single address space is a major contributing  factor  to  the
     overall  simplicity  of  CMOS.   Not only is the operating system
     relieved  of  address  space   management   chores,   but   also,
     programming  and  debugging  are  generally facilitated.  Second,
     data  sharing  among  processes  is   direct,   convenient,   and
     efficient.   In multiple address space systems, memory sharing is
     often a difficult problem.  Third, I/O devices have direct access
     to all of memory.  In multiple address space systems, I/O devices
     are typically restricted to a single address space.   This  often
     produces  a need for extra data copying, especially in connection
     with DMA devices.   Fourth,  an  entire  CMOS  system  is  linked
     together as one composite program.  This means that non-identical
     processes can still share a single copy  of  common  subroutines.
     Multiple address space systems usually cannot match this level of
     code-space efficiency.  The large address space provided by  CMOS
     obviates  the need to artificially split systems into a number of
     Stern, Ruth, and Haverty       -4-                    Version 1.0
     IEN 164                   January 1981               Preliminary
     processes because of the address space limitations.
     3  Process Management
          CMOS processes are defined at compilation time.  They cannot
     be dynamically created or destroyed during system operation.  For
     each process, a set of basic attributes is specified including  a
     name, an initial program entrypoint, and a stack size.
          CMOS employs a rudimentary process scheduling method.  Three
     process  states  are defined:  (1) running; (2) ready to run; and
     (3) waiting for an event.   A  running  process  always  runs  to
     completion.   This  means that the processor is relinquished only
     by explicit action of the running process.   It  is  never  taken
     away  by the operating system.  There is no time-slicing or other
     form of preemption.  The next process to run  is  selected  by  a
     simple  round-robin  algorithm.   All  processes  have  a uniform
     scheduling priority.
          This  non-preemptive  scheduling  discipline  has  important
     implications.    First,   processes   must  be  designed  not  to
     monopolize the  processor  for  long  time  periods.   Otherwise,
     crucial  tasks  may  fail  to  be  serviced  in a timely fashion.
     Second, critical program sections (i.e.,  program  sections  that
     can  be  safely  entered  by  only one process at a time) need no
     explicit protection.  The absence of  preemption  guarantees  the
     integrity of critical program sections.
          Interrupt handling creates  a  separate  class  of  critical
     sections  that  are  not  protected by the scheduling discipline.
     These critical sections exist only within  the  operating  system
     and  are  of  no  concern to application programs.  CMOS protects
     these  critical  sections  in  the  standard  manner  (viz.,   by
     temporarily disabling interrupts).
     4  Interprocess Communication
          CMOS processes  communicate  with  one  another  by  passing
     messages  known  as  "events".   For  this purpose, the operating
     system provides primitives called "signal", "wait",  and  "recv".
     The  signal  primitive  permits  a  process  to  send an event to
     another process.  The wait primitive permits a  process  to  wait
     for  an  event  that  may  or  may  not  have  arrived.  The recv
     primitive permits a process to receive an event that has  already
     arrived.
     Stern, Ruth, and Haverty       -5-                    Version 1.0
     IEN 164                   January 1981               Preliminary
          An event message contains the sender process  ID,  an  event
     ID,  and  one  word of unspecified data.  The event ID is used to
     indicate the type of event.  Both the wait and receive primitives
     allow  a  process  to select the event IDs of immediate interest.
     The meaning of the data word depends on the event  type.   It  is
     quite  common  for the data word to contain a pointer to a larger
     data structure.
          CMOS provides  a  facility  that  helps  to  automate  event
     processing activities.  A process can designate a procedure to be
     the event handler for a particular event type.   Thereafter,  the
     event  handler  becomes active whenever a special wait primitive,
     called "waith", is  invoked.   For  each  event  received,  waith
     checks  to  see if an event handler has been defined.  If so, the
     event handler procedure is automatically dispatched.  This  frees
     the  caller  of  waith  from the responsibility of having to deal
     with events not of direct interest.  Processing of  these  events
     can be viewed as a background activity.
     5  Input/Output
          CMOS provides an asynchronous I/O facility.  To perform I/O,
     a  process  creates  an  I/O  request  block  (IORB).   The  IORB
     identifies the target device, the type of operation (e.g.,  read,
     write,   abort),  and  information  relevant  to  the  particular
     operation (e.g., buffer areas for data transfer).  The IORB  also
     specifies  an  event  ID.   To  initiate  processing, the IORB is
     passed to the operating system.  When the request  is  completed,
     the  operating system signals an event to the requesting process.
     The event message contains the event ID taken from the IORB and a
     data  word  that  contains the address of the IORB.  In this way,
     the requesting process can easily associate the completion  event
     with the original request.  Status information is returned in the
     IORB.
          A process can direct I/O  to  a  specific  device  or  to  a
     special  "primary" device.  Primary devices are defined on a per-
     process basis and can be either assigned (to a  specific  device)
     or  unassigned.   If  a  process  attempts  to  perform I/O on an
     unassigned primary device,  the  process  is  suspended  until  a
     primary  device  is assigned.  This permits a single device to be
     moved from one process to another and thereby provides  a  simple
     way to share a terminal among several processes.
          The core of the CMOS  I/O  system  is  a  device-independent
     module,  "eior"  (enter I/O request), that provides a centralized
     interface between the application program and the various  device
     driver modules.  As described above, this interface accepts IORBs
     from the application program.  The IORBs are automatically queued
     Stern, Ruth, and Haverty       -6-                    Version 1.0
     IEN 164                   January 1981               Preliminary
     on  a  per-device  basis.   If  desired,  requests from different
     processes can be interspersed for the same device.  When a device
     becomes  ready  to accept the next request, the first IORB in the
     device queue, if any, is passed to the appropriate device  driver
     module.
          All device driver modules provide a  standardized  interface
     expected by the core I/O system.  This interface consists of four
     entrypoints:  (1) a configuration entry;  (2)  an  initialization
     entry;  (3)  a request entry; and (4) an interrupt handler entry.
     A system configuration table specifies the  driver  configuration
     entry   for  each  device.   During  system  initialization,  the
     configuration entry is invoked to obtain the other  three  driver
     entrypoints, and the size of any per-device data base required by
     the driver.  The initialization entry  is  invoked  automatically
     before  the  first IORB is passed to the driver.  The request and
     interrupt  handler  entries  perform  standard   device   control
     functions.    At   present,  CMOS  includes  driver  modules  for
     asynchronous terminals and for 1822 network interfaces.
     6  Memory Allocation
          CMOS includes routines that allocate and  deallocate  blocks
     of  memory  from  a free storage pool.  Both the operating system
     and  the  application  program  share  a  common   pool.    Three
     allocation  options  are  available  to  control operating system
     behavior in the case of an  allocation  failure:  (1)  return  an
     error code; (2) wait for more memory to become available; and (3)
     cease system operation.
          CMOS  provides  an  allocation  mechanism   only,   not   an
     allocation  policy.  The policy, of course, is the responsibility
     of  the  application  program.    In   practice,   however,   few
     application  programs incorporate a memory allocation policy that
     eliminates the possibility of free  space  exhaustion.   Instead,
     some  applications include a recovery mechanism to deal with this
     problem.  It is reasonable to expect that such a  mechanism  will
     depend  upon  the  continued functioning of the operating system.
     Therefore,  the  operating  system   must   not   itself   become
     immediately disabled as a result of free space exhaustion.
          To prevent disablement, CMOS  depends  on  "reserve  storage
     pools".  A separate reserve storage pool is created for each type
     of object needed by a crucial  function.   The  operating  system
     uses  two  such  pools,  one for event messages and one for timer
     queue entries.  Reserve storage  pools  are  managed  by  special
     allocation  and  deallocation  routines.   The special allocation
     routine first attempts to obtain space from the common pool.   If
     this  fails, space is taken instead from the reserve pool and the
     Stern, Ruth, and Haverty       -7-                    Version 1.0
     IEN 164                   January 1981               Preliminary
     caller is so informed.  If the reserve  pool  is  exhausted,  the
     system dies.
          System primitives that use reserve storage pools  return  an
     indication   of   when  reserve  storage  has  been  tapped.   An
     application program can therefore detect free space exhaustion by
     this  means  or  by  the  direct  failure  of a simple allocation
     request.  At this point, the operating system  will  continue  to
     function  for a period of time (or number of calls) determined by
     reserve storage pool sizes.
     7  System Clock
          CMOS provides a clock management facility that  maintains  a
     time-of-day  clock  and  permits  processes  to set "alarms".  An
     alarm is simply an event that is signalled by the  clock  manager
     after a specified time period has elapsed.  Both the event ID and
     the data word of the event message are specified by  the  process
     that  sets the alarm.  An alarm can be either a one-time alarm or
     an interval alarm  that  is  automatically  repeated  at  regular
     intervals.
     8  Software Development Tools
          All programming support for CMOS software development is now
     provided by the UNIX time-sharing system, via the UNIX C compiler
     and linker.   BBN  has  developed  a  Version  7  UNIX  and  a  C
     compiler/linker to run on the C-machines.
          The same hardware configuration of a C-machine  can  support
     both  the  UNIX and CMOS systems, although not simultaneously, of
     course.  We plan to use the  UNIX  system  development  tools  to
     create  CMOS  systems,  which  can  then  be  run  and  tested by
     bootstrapping the CMOS code in place  of  UNIX  on  the  same  or
     different hardware.
     9  Future Development
          There is a variety of possible  extensions  to  CMOS,  which
     take  advantage  of  the  increased  flexibility  provided by the
     hardware  base.   We  intend  to   pursue   these   as   specific
     applications arise which require additional functionality.
     Stern, Ruth, and Haverty       -8-                    Version 1.0
     IEN 164                   January 1981               Preliminary
          The most interesting category of extensions involves the use
     of  the memory mapping hardware available for C machines.  In the
     standard  C-machine  configuration,  the  20-bit  address   space
     provides access to a physical memory of 1 Mbyte.
          Within this physical address space, processes can share  any
     or  all  of the memory, since the process address space is also 1
     Mbyte.
          The   memory   mapper   hardware   extends   the   machine's
     capabilities  in  two  ways.   The  first  extension provides for
     support of  2  Mbytes  of  physical  memory.   Each  process  is,
     however,  limited  to  1  Mbyte  of  address  space.   The second
     extension lies in the ability of the memory map to support  eight
     independent  active process maps.  This creates an environment in
     which processes can share portions of their address  spaces  with
     the  system  or  other  processes,  with  fast  context switching
     between the eight active processes.   This  removes  two  of  the
     basic  limitations we have encountered in real-time designs based
     on  PDP-11  architectures,  namely,  the  granularity  of  memory
     sharing and the speed of context switching.
          The CMOS environment has not yet been  extended  to  utilize
     these  additional  facilities,  although  we anticipate that this
     effort will begin soon.
     10  CMOS System Calls
          This section describes CMOS system calls  available  to  the
     application  programmer.   These calls are divided into two major
     groups, low-level  functions  and  higher-level  functions.   The
     low-level  functions correspond roughly to the MOS interface, and
     the   higher-level   functions   provide    certain    additional
     capabilities.   The  usage  of  each  system call is described in
     terms of the C language.  Two typedefs are first defined and then
     referenced by a few of the system call descriptions.
     typedef struct {                /* event message buffer */
             char msevent;           /* event ID */
             char mssender;          /* sender process ID */
             int msdata;             /* user data */
     } MSG;
     Stern, Ruth, and Haverty       -9-                    Version 1.0
     IEN 164                   January 1981               Preliminary
     typedef struct iorb {           /* I/O request block */
             struct iorb *irnextp;   /* ptr to next IORB on chain */
             int irdevid;            /* device ID */
             char irevent;           /* completion signal event */
             char irpid;             /* requestor's process ID */
             char *irbufp;           /* buffer ptr */
             char irport;            /* port number of request */
             char iropcode;          /* operation code */
             int irbufsiz;           /* buffer size (in bytes) */
             int irstatus;           /* status of I/O operation */
             int irnxfer;            /* number of bytes transferred */
             int irpad[2];           /* mysterious padding */
     } IORB;
     Stern, Ruth, and Haverty      -10-                   Version 1.0
     IEN 164                   January 1981               Preliminary
                            LOW-LEVEL FUNCTIONS
     Process Attributes
     Name:     getpid
     Function: convert process name to process ID
     Usage:    pid = getpid (name)
               char name[];  /* process name to convert
                                null name => calling process */
               int pid;      /* process ID for given name */
     Name:     getpn
     Function: convert process ID to process name
     Usage:    pn = getpn (pid, namep)
               int pid;      /* process ID to convert
                                0 => calling process */
               char *namep;  /* place to store name */
               char *pn;     /* same as namep */
     Name:     getprio
     Function: get primary I/O devices of specified process
     Usage:    getprio (pid, priop)
               int pid;      /* process ID, 0 => calling process */
               struct {
                int idevid;  /* primary input device ID */
                int odevid;  /* primary output device ID */
               } *priop;
     Stern, Ruth, and Haverty      -11-                   Version 1.0
     IEN 164                   January 1981               Preliminary
     Name:     setprio
     Function: set primary I/O devices of specified process
     Usage:    setprio (pid, idevid, odevid)
               int pid;      /* process ID, 0 => calling process */
               int idevid;   /* input device ID, <0 => no change */
               int odevid;   /* output device ID, <0 => no change */
     Name:     movprio
     Function: move primary I/O devices of caller to another process
     Usage:    movprio (pid)
               int pid;      /* target process ID */
     Device Attributes
     Name:     getdid
     Function: convert device name to device ID
     Usage:    devid = getdid (name)
               char name[];  /* device name to convert */
               int devid;    /* device ID */
     Name:     getdn
     Function: convert device ID to device name
     Usage:    dn = getdn (devid, namep)
               int devid;    /* device ID to convert */
               char *namep;  /* place to store name */
               char *dn;     /* same as namep */
     Stern, Ruth, and Haverty      -12-                   Version 1.0
     IEN 164                   January 1981               Preliminary
     Input/Output
     Name:     eior
     Function: enter an I/O request
     Usage:    ec = eior (iorbp)
               IORB *iorbp;  /* I/O request block ptr */
               int ec;       /* error code */
     Interprocess Communication
     Name:     signal
     Function: signal an event to a process
     Usage:    sw = signal (pid, event, data)
               char pid;     /* target process  ID */
               char event;   /* event number */
               int data;     /* data for target process */
               int sw;       /* 1 if reserve pool used to queue
                                signal, else 0 */
     Name:     wait
     Function: wait for any event
     Usage:    wait (msgp)
               MSG *msgp;    /* ptr to message buffer */
     Name:     waits
     Function: wait for a single specified event
     Usage:    waits (event, msgp)
               char event;   /* desired event */
               MSG *msgp;    /* message buffer ptr */
     Stern, Ruth, and Haverty      -13-                   Version 1.0
     IEN 164                   January 1981               Preliminary
     Name:     waitm
     Function: wait for one of multiple specified events
     Usage:    waitm (evlist, nev, msgp);
               char *evlist; /* event list (array) */
               int nev;      /* number of events in list */
               MSG *msgp;    /* message buffer ptr */
     Name:     recv
     Function: receive any pending event
     Usage:    sw = recv (msgp)
               MSG *msgp;    /* ptr to message buffer */
               int sw;       /* 1 if event returned, else 0 */
     Name:     recvs
     Function: receive a single specified pending event
     Usage:    sw = recvs (event, msgp)
               char event;   /* desired event */
               MSG *msgp;    /* message buffer ptr */
               int sw;       /* 1 if event returned, else 0 */
     Name:     recvm
     Function: receive one of multiple specified pending events
     Usage:    sw = recvm (evlist, nev, msgp);
               char *evlist; /* event list (array) */
               int nev;      /* number of events in list */
               MSG *msgp;    /* message buffer ptr */
               int sw;       /* 1 if event returned, else 0 */
     Stern, Ruth, and Haverty      -14-                   Version 1.0
     IEN 164                   January 1981               Preliminary
     Memory Allocation
     Name:     alloc
     Function: allocate memory block, return if not available
     Usage:    blkp = alloc (nbytes)
               int nbytes;   /* size of block desired */
               char *blkp;   /* ptr to allocated block, else null */
     Name:     allocw
     Function: allocate memory block, wait if not available
     Usage:    blkp = allocw (nbytes)
               int nbytes;   /* size of block desired */
               char *blkp;   /* ptr to allocated block */
     Name:     allocd
     Function: allocate memory block, die if not available
     Usage:    blkp = allocd (nbytes)
               int nbytes;   /* size of block desired */
               char *blkp;   /* ptr to allocated block */
     Name:     free
     Function: free a previously allocated block
     Usage:    free (blkp)
               char *blkp;   /* ptr to block */
     Stern, Ruth, and Haverty      -15-                   Version 1.0
     IEN 164                   January 1981               Preliminary
     System Clock Management
     Name:     alarm
     Function: set alarm to awaken process
     Usage:    sw = alarm (event, data, delay)
               char event;   /* signal event */
               int data;     /* signal data */
               int delay;    /* timeout period in seconds/60 */
               int sw;       /* 1 if reserve pool used to queue
     Name:     ialarm
     Function: set alarm to awaken process at regular intervals
     Usage:    sw = ialarm (event, data, interval)
               char event;   /* signal event */
               int data;     /* signal data */
               int interval; /* timeout interval in seconds/60 */
               int sw;       /* 1 if reserve pool used to queue
     Name:     kalarm
     Function: kill any specified pending alarms
     Usage:    kalarm (event, data)
               char event;   /* event of requests to kill */
               int data;     /* data of requests to kill */
     Name:     setod
     Function: set time of day
     Usage:    setod (time)
               long time;    /* time of day */
     Stern, Ruth, and Haverty      -16-                   Version 1.0
     IEN 164                   January 1981               Preliminary
     Name:     getod
     Function: get time of day
     Usage:    time = getod ()
               long time;    /* time of day */
     Stern, Ruth, and Haverty      -17-                   Version 1.0
     IEN 164                   January 1981               Preliminary
                          HIGHER-LEVEL FUNCTIONS
     Event Management
     Name:     newev
     Function: generate a new event number, unique system-wide
     Usage:    event = newev ()
               char event;   /* event number */
     Name:     setevh
     Function: associate an event handler routine with a specified
               event for this process
     Usage:    oldent = setevh (event, entryp)
               char event;   /* event to be handled */
               int (*entryp) (); /* event handler entrypoint */
                             /* if null, cancel event handler */
               int (*oldent) (); /* previous entryp, else null */
     Name:     waith
     Function: wait for an event; dispatch event handler if one
               is defined, else return.
     Usage:    waith (msgp)
               MSG *msgp;    /* ptr to message buffer */
     Name:     waitsh
     Function: wait for an event; dispatch event handler if one is
               defined; else return if event is the one specified;
               else ignore event;
     Usage:    waitsh (event, msgp)
               char event;   /* desired event */
               MSG *msgp;    /* message buffer ptr */
     Stern, Ruth, and Haverty      -18-                   Version 1.0
     IEN 164                   January 1981               Preliminary
     Synchronous Input/Output
     Name:     read
     Function: read from a specified device; event handlers are
               active while awaiting read completion.
     Usage:    nbytes = read (devid, bufp, bufsiz)
               int devid;    /* device ID */
               char *bufp;   /* buffer ptr */
               int bufsiz;   /* buffer size */
               int nbytes;   /* number of bytes read */
     Name:     write
     Function: write to a specified device; event handlers are
               NOT active while awaiting write completion.
     Usage:    nbytes = write (devid, bufp, bufsiz)
               int devid;    /* device ID */
               char *bufp;   /* buffer ptr */
               int bufsiz;   /* buffer size */
               int nbytes;   /* number of bytes written */
     11  System Generation
          The following CMOS modules must be linked  into  any  system
     configuration:
          cm_init         Initialization routines.
          cm_data         Process control and configuration tables.
          cm_util         CMOS utilities.
          cm_err          Error message routines.
          cm_proc         Basic process management routines.
          cm_queue        Queue manipulation routines.
          cm_ipc          Interprocess communication routines.
          cm_mem          Memory management primitives.
     Stern, Ruth, and Haverty      -19-                   Version 1.0
     IEN 164                   January 1981               Preliminary
          cm_io           Basic I/O routines.
     In addition to  the  required  modules,  the  following  optional
     modules may be included for specific hardware device support:
          cm_time         Timer management routines.
          cm_tty          Terminal driver routines (to be rewritten).
          cm_1822         1822 driver routines (to be written).
          cm_smd          Disk driver routines (to be written).
          cm_mlc          MLC driver routines (to be written).
     In order to include DDT the following modules must be included:
          ddt_main
          ddt_cmd
          ddt_code
          ddt_brk
          ddt_sym
     Stern, Ruth, and Haverty      -20-                   Version 1.0
     IEN 164                   January 1981               Preliminary
                                References
     1. Mathis, J. and  Klemba,  K.,  "The  Micro  Operating  System,"
     Chapter  6  of  Terminal  Interface  Unit  Notebook,  Vol. 2, SRI
     International, March 1980.  <MOS reference>
     2.  Kraley,  M.  et  al.,  "Design  of  a  User-microprogrammable
     Building  Block," Thirteenth Annual Workshop on Microprogramming,
     Colorado Springs, Colorado, 1980.
     3.  Ritchie,  D.M.  and  Thompson,  K.,  "The  UNIX  Time-Sharing
     System,"  Bell  System  Technical  Journal  57(6)  pp.  1905-1929
     (1978).
     4. Kernighan, B.W. and Ritchie, D.M., The C Programming Language,
     Prentice-Hall, Inc., 1978.
     Stern, Ruth, and Haverty      -21-                   Version 1.0
     IEN 164                   January 1981               Preliminary
                                 APPENDIX
                  CMOS Error Messages (C-machine version)
     cvdevnm: Device not found
          The mate specified for a device (in the device control table
          initialization data) is not the name of any existing device.
     getdcte: Bad device ID
          The CMOS primitive (e.g. eior, getdn)  was  called  with  an
          invalid device id.
     dlvrmsg: NULL msg ptr
          Due to an internal error (blush).
     mkroom: Memory full
          Insufficient space in the free memory  pool  to  accommodate
          device  driver  data  and/or  process  stacks  during system
          initialization.
     alloc: Invalid request
          The CMOS primitive "alloc" has been called with  a  negative
          block size.
     free: Invalid addr
          The CMOS primitive "free" has been  called  with  a  pointer
          outside the free memory pool.
     allocd: Allocation failed
          An allocation request via the CMOS  primitive  "allocd"  has
          failed.
     plalloc: Pool empty
          The reserve memory pool has been exhausted.
     Stern, Ruth, and Haverty      -22-                   Version 1.0
     IEN 164                   January 1981               Preliminary
     dschd: Stack overflow
          A process has overrun its stack.  This  may  be  due  to  an
          excessive   depth  of  nested  procedure  calls.   The  only
          solution is to reassemble the system with more stack space.
     getpcte: Bad pid
          A CMOS primitive was called with a non-existent process id.
     mktqe: Bad delay time
          A CMOS clock management primitive was given a timeout period
          of 0 by the caller.
     In addition, there are various fatal conditions trapped by CMOS:
          TRAP: invalid memory addr
          TRAP: illegal instruction
          TRAP: illegal micro call
          TRAP: privileged operation
          TRAP: register overflow
          TRAP: EDAC error
          TRAP: register underflow
     For every trap the following machine status  values  are  printed
     out:
          PC = program counter
          PS = program status
          SP = stack pointer
     Stern, Ruth, and Haverty      -23-                   Version 1.0
/data/webs/external/dokuwiki/data/pages/rfc/ien/ien164.txt · Last modified: 2001/06/25 19:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki