Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ master(4) — 4D1 2.0

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

system(4)

lboot(1M)



     MASTER(4)                                               MASTER(4)



     NAME
          master - master configuration database

     DESCRIPTION
          The master configuration database is a collection of files.
          Each file contains configuration information for a device or
          module that may be included in the system.  A file is named
          with the module name to which it applies.  This collection
          of files is maintained in a directory called
          /usr/sysgen/master.d.  Each individual file has an identical
          format.  For convenience, this collection of files will be
          referred to as the master file, as though it was a single
          file.  This will allow a reference to the master file to be
          understood to mean the individual file in the master.d
          directory that corresponds to the name of a device or
          module.  The file is used by the lboot(1M) program to obtain
          device information to generate the device driver and
          configurable module files.  master consists of two parts;
          they are separated by a line with a dollar sign ($) in
          column 1.  Part 1 contains device information for both
          hardware and software devices, and loadable modules.  Part 2
          contains parameter declarations.  Any line with an asterisk
          (*) in column 1 is treated as a comment.

        Part 1, Description
          Hardware devices, software drivers and loadable modules are
          defined with a line containing the following information.
          Field 1 must begin in the left most position on the line.
          Fields are separated by white space (tab or blank).

               Field 1:    element characteristics:
                           o           specify only once
                           r           required device
                           b           block device
                           c           character device
                           t           initialize cdevsw[].d_ttys
                           j           file system
                           s           software driver
                           f           STREAMS driver
                           m           STREAMS module
                           x           not a driver; a loadable module
                           k           kernel module
               Field 2:    handler prefix (14 chars. maximum)
               Field 3:    software driver external major number; "-"
                           if not a software driver, or to be assigned
                           during execution of lboot(1M)
               Field 4:    number of sub-devices per device; "-" if
                           none
               Field 5:    dependency list (optional); this is a comma
                           separated list of other drivers or modules
                           that must be present in the configuration
                           if this module is to be included



     Page 1                                        (last mod. 8/20/87)





     MASTER(4)                                               MASTER(4)



               For each module, two classes of information are
               required by lboot(1M):  external routine references and
               variable definitions.  Routine lines begin with white
               space white space and immediately follow the initial
               module specification line.  These lines are free form,
               thus they may be continued arbitrarily between non-
               blank tokens as long as the first character of a line
               is white space.  Variable definition lines begin after
               a line that contains a '$' in column one.  Variable
               definitions follow C language conventions, with slight
               modifications.

        Part 1, Routine Reference Lines
          If the UNIX system kernel or other dependent module contains
          external references to a module, but the module is not
          configured, then these external references would be
          undefined.  Therefore, the routine reference lines are used
          to provide the information necessary to generate appropriate
          dummy functions at boot time when the driver is not loaded.
          Routine references are defined as follows:
               Field 1:    routine name ()
               Field 2:    the routine type: one of
                           {}   routine_name(){}
                           {nulldev}
                                routine_name(){nulldev();}
                           {nosys}
                                routine_name(){return nosys();}
                           {nodev}
                                routine_name(){return nodev();}
                           {false}
                                routine_name(){return 0;}
                           {true}
                                routine_name(){return 1;}
                           {fsnull}
                                routine_name(){return fsnull();}
                           {fsstray}
                                routine_name(){return fsstray();}
                           {nopkg}
                                routine_name(){nopkg();}
                           {noreach}
                                routine_name(){noreach();}

        Part 2, Variables
          Variables may be declared and (optionally) statically
          initialized on lines after a line whose first character is a
          dollar sign ('$').  Variable definitions follow standard C
          syntax for global declarations, with the following in-line
          substitutions:

               ##M         the internal major number assigned to the
                           current module if it is a device driver;
                           zero of this module is not a device driver



     Page 2                                        (last mod. 8/20/87)





     MASTER(4)                                               MASTER(4)



                           ##E the external major number assigned to
                           the current module; either explicitly
                           defined by the current master file entry,
                           or assigned by lboot(1M)
               ##C         number of controllers present; this number
                           is determined dynamically by lboot(1M) for
                           hardware devices, or by the number provided
                           in the system file for non-hardware drivers
                           or modules
               ##D         number of devices per controller taken
                           directly from the current master file entry

     EXAMPLES
          A sample master file for a shared memory module would be
          named "shm".  The module is an optional loadable software
          module that can only be specified once.  The module prefix
          is shm, and it has no major number associated with it.  In
          addition, another module named "ipc" is necessary for the
          correct operation of this module.

          *FLAG PREFIX SOFT #DEV DEPENDENCIES
          ox    shm    -     -    ipc
                         shmsys(){nosys}
                         shmexec(){}
                         shmexit(){}
                         shmfork(){}
                         shmslp(){true}
                         shmtext(){}
          $
          #define SHMMAX 131072
          #define SHMMIN 1
          #define SHMMNI 100
          #define SHMSEG 6
          #define SHMALL 512

          struct shmid_ds shmem[SHMMNI];
          struct shminfo shminfo = {
               SHMMAX,
               SHMMIN,
               SHMMNI,
               SHMSEG,
               SHMALL,
          };

          This master file will cause routines named shmsys, shmexec,
          etc., to be generated by the boot program if the shm driver
          is not loaded, and there is a reference to this routine from
          any other module loaded.  When the driver is loaded, the
          structure array shmem will be allocated, and the structure
          shminfo allocated and initialized.  will be allocated and
          initialized as specified.




     Page 3                                        (last mod. 8/20/87)





     MASTER(4)                                               MASTER(4)



          A sample master file for a VME disk driver would be named
          "dkip" The driver is a block and a character device, the
          driver prefix is dkip, and the external major number is 4.
          The VME interrupt priority level and vector numbers are
          declared in the system file /usr/sysgen/system (see
          lboot(1M)).

          *FLAG PREFIX SOFT #DEV DEPENDENCIES
          bc    dkip4   -    -   io

          $$$
          /* disk driver variable tables */
          #include "sys/dvh.h"
          #include "sys/dkipreg.h"
          #include "sys/elog.h"

          struct iotime dkipiotime[##C][DKIPUPC]; /* io statistics */
          struct iobuf dkipctab[##C];             /* controller queues */
          struct iobuf dkiputab[##C][DKIPUPC];         /* drive queues */
          int dkipmajor = ##E;               /* external major # */

          This master file will cause entries in the block and
          character device switch tables to be generated, if this
          module is loaded.  Since this is a hardware device (implied
          by the block and character flags), VME interrupt structures
          will be generated, also, by the boot program.  The declared
          arrays will all be sized to the number of controllers
          present, which is determined by the boot program, based on
          information in the system file /usr/sysgen/system.

     FILES
          /usr/sysgen/master.d/*
          /usr/sysgen/system

     SEE ALSO
          system(4), lboot(1M)
     ORIGIN
          AT&T V.3

















     Page 4                                        (last mod. 8/20/87)



Typewritten Software • bear@typewritten.org • Edmonds, WA 98026