This section is not for the novice, it describes some of the inner workings of the configuration process as well as the pertinent parts of the system autoconfiguration process. It is intended to give those people who intend to install new device drivers and/or other system facilities sufficient information to do so in the manner which will allow others to easily share the changes.
This section is broken into four parts:
If you wish to make site-specific modifications to the system it is best to bracket them with
#ifdef SITENAME ... #endif
#ifndef SITENAME ... #endif
Indicate machine-specific code with ``#ifdef vax'' (or other machine, as appropriate). 4.4BSD underwent extensive work to make it extremely portable to machines with similar architectures- you may someday find yourself trying to use a single copy of the source code on multiple machines.
This section considers the work needed to augment config's data base files for non-standard system facilities. Config uses a set of files that list the source modules that may be required when building a system. The data bases are taken from the directory in which config is run, normally /sys/conf. Three such files may be used: files, files.machine, and files.ident. The first is common to all systems, the second contains files unique to a single machine type, and the third is an optional list of modules for use on a specific machine. This last file may override specifications in the first two. The format of the files file has grown somewhat complex over time. Entries are normally of the form
dir/source.c type option-list modifiers
for example,
vaxuba/foo.c optional foo device-driver
The type is one of standard or optional. Files marked as standard are included in all system configurations. Optional file specifications include a list of one or more system options that together require the inclusion of this module. The options in the list may be either names of devices that may be in the configuration file, or the names of system options that may be defined. An optional file may be listed multiple times with different options; if all of the options for any of the entries are satisfied, the module is included.
If a file is specified as a device-driver, any special compilation options for device drivers will be invoked. On the VAX this results in the use of the -i option for the C optimizer. This is required when pointer references are made to memory locations in the VAX I/O address space.
Two other optional keywords modify the usage of the file. Config understands that certain files are used especially for kernel profiling. These files are indicated in the files files with a profiling-routine keyword. For example, the current profiling subroutines are sequestered off in a separate file with the following entry:
sys/subr_mcount.c optional profiling-routine
The profiling-routine keyword forces config not to compile the source file with the -pg option.
The second keyword which can be of use is the config-dependent keyword. This causes config to compile the indicated module with the global configuration parameters. This allows certain modules, such as machdep.c to size system data structures based on the maximum number of users configured for the system.
The I/O system and config have been designed to easily allow new device support to be added. The system source directories are organized as follows:
/sys/h machine independent include files /sys/sys machine-independent system source files /sys/conf site configuration files and basic templates /sys/net network-protocol-independent, but network-related code /sys/netinet DARPA Internet code /sys/netimp IMP support code /sys/netns Xerox NS code /sys/vax VAX-specific mainline code /sys/vaxif VAX network interface code /sys/vaxmba VAX MASSBUS device drivers and related code /sys/vaxuba VAX UNIBUS device drivers and related code
Existing block and character device drivers for the VAX reside in ``/sys/vax'', ``/sys/vaxmba'', and ``/sys/vaxuba''. Network interface drivers reside in ``/sys/vaxif''. Any new device drivers should be placed in the appropriate source code directory and named so as not to conflict with existing devices. Normally, definitions for things like device registers are placed in a separate file in the same directory. For example, the ``dh'' device driver is named ``dh.c'' and its associated include file is named ``dhreg.h''.
Once the source for the device driver has been placed in a directory, the file ``/sys/conf/files.machine'', and possibly ``/sys/conf/devices.machine'' should be modified. The files files in the conf directory contain a line for each C source or binary-only file in the system. Those files which are machine independent are located in ``/sys/conf/files,'' while machine specific files are in ``/sys/conf/files.machine.'' The ``devices.machine'' file is used to map device names to major block device numbers. If the device driver being added provides support for a new disk you will want to modify this file (the format is obvious).
In addition to including the driver in the files file, it must also be added to the device configuration tables. These are located in ``/sys/vax/conf.c'', or similar for machines other than the VAX. If you don't understand what to add to this file, you should study an entry for an existing driver. Remember that the position in the device table specifies the major device number. The block major number is needed in the ``devices.machine'' file if the device is a disk.
With the configuration information in place, your configuration
file appropriately modified, and a system reconfigured and rebooted
you should incorporate the shell commands needed to install the special
files in the file system to the file ``/dev/MAKEDEV'' or
``/dev/MAKEDEV.local''. This is discussed in the document ``Installing
and Operating 4.4BSD''.
APPENDIX A. CONFIGURATION FILE GRAMMAR
The following grammar is a compressed form of the actual yacc(1) grammar used by config to parse configuration files. Terminal symbols are shown all in upper case, literals are emboldened; optional clauses are enclosed in brackets, ``['' and ``]''; zero or more instantiations are denoted with ``*''.
Configuration ::= [ Spec ; ]* Spec ::= Config_spec | Device_spec | trace | /* lambda */ /* configuration specifications */ Config_spec ::= machine ID | cpu ID | options Opt_list | ident ID | System_spec | timezone [ - ] NUMBER [ dst [ NUMBER ] ] | timezone [ - ] FPNUMBER [ dst [ NUMBER ] ] | maxusers NUMBER /* system configuration specifications */ System_spec ::= config ID System_parameter [ System_parameter ]* System_parameter ::= swap_spec | root_spec | dump_spec | arg_spec swap_spec ::= swap [ on ] swap_dev [ and swap_dev ]* swap_dev ::= dev_spec [ size NUMBER ] root_spec ::= root [ on ] dev_spec dump_spec ::= dumps [ on ] dev_spec arg_spec ::= args [ on ] dev_spec dev_spec ::= dev_name | major_minor major_minor ::= major NUMBER minor NUMBER dev_name ::= ID [ NUMBER [ ID ] ] /* option specifications */ Opt_list ::= Option [ , Option ]* Option ::= ID [ = Opt_value ] Opt_value ::= ID | NUMBER Mkopt_list ::= Mkoption [ , Mkoption ]* Mkoption ::= ID = Opt_value /* device specifications */ Device_spec ::= device Dev_name Dev_info Int_spec | master Dev_name Dev_info | disk Dev_name Dev_info | tape Dev_name Dev_info | controller Dev_name Dev_info [ Int_spec ] | pseudo-device Dev [ NUMBER ] Dev_name ::= Dev NUMBER Dev ::= uba | mba | ID Dev_info ::= Con_info [ Info ]* Con_info ::= at Dev NUMBER | at nexus NUMBER Info ::= csr NUMBER | drive NUMBER | slave NUMBER | flags NUMBER Int_spec ::= vector ID [ ID ]* | priority NUMBER
The terminal symbols are loosely defined as:
In special instances a question mark, ``?'', can be substituted for a ``NUMBER'' token. This is used to effect wildcarding in device interconnection specifications.
Comments in configuration files are indicated by a ``#'' character at the beginning of the line; the remainder of the line is discarded.
A specification
is interpreted as a continuation of the previous line
if the first character of the line is tab.
APPENDIX B. RULES FOR DEFAULTING SYSTEM DEVICES
When config processes a ``config'' rule which does not fully specify the location of the root file system, paging area(s), device for system dumps, and device for argument list processing it applies a set of rules to define those values left unspecified. The following list of rules are used in defaulting system devices.
The following table summarizes the default partitions selected when a device specification is incomplete, e.g. ``hp0''.
Type Partition ------------------ root ``a'' swap ``b'' args ``b'' dumps ``b''
When multiple swap partitions are specified, the system treats the first specified as a ``primary'' swap area which is always used. The remaining partitions are then interleaved into the paging system at the time a swapon(2) system call is made. This is normally done at boot time with a call to swapon(8) from the /etc/rc file.
System dumps are automatically taken after a system crash, provided the device driver for the ``dumps'' device supports this. The dump contains the contents of memory, but not the swap areas. Normally the dump device is a disk in which case the information is copied to a location at the back of the partition. The dump is placed in the back of the partition because the primary swap and dump device are commonly the same device and this allows the system to be rebooted without immediately overwriting the saved information. When a dump has occurred, the system variable dumpsize is set to a non-zero value indicating the size (in bytes) of the dump. The savecore(8) program then copies the information from the dump partition to a file in a ``crash'' directory and also makes a copy of the system which was running at the time of the crash (usually ``/kernel''). The offset to the system dump is defined in the system variable dumplo (a sector offset from the front of the dump partition). The savecore program operates by reading the contents of dumplo, dumpdev, and dumpmagic from /dev/kmem, then comparing the value of dumpmagic read from /dev/kmem to that located in corresponding location in the dump area of the dump partition. If a match is found, savecore assumes a crash occurred and reads dumpsize from the dump area of the dump partition. This value is then used in copying the system dump. Refer to savecore(8) for more information about its operation.
The value dumplo is calculated to be
dumpdev-size - memsize
The following configuration files are developed in section 5; they are included here for completeness.
# # ANSEL VAX (a picture perfect machine) # machine vax cpu VAX780 timezone 8 dst ident ANSEL maxusers 40 config kernel root on hp0 config hpkernel root on hp0 swap on hp0 and hp2 config genkernel swap generic controller mba0 at nexus ? disk hp0 at mba? disk ? disk hp1 at mba? disk ? controller mba1 at nexus ? disk hp2 at mba? disk ? disk hp3 at mba? disk ? controller uba0 at nexus ? controller tm0 at uba? csr 0172520 vector tmintr tape te0 at tm0 drive 0 tape te1 at tm0 drive 1 device dh0 at uba? csr 0160020 vector dhrint dhxint device dm0 at uba? csr 0170500 vector dmintr device dh1 at uba? csr 0160040 vector dhrint dhxint device dh2 at uba? csr 0160060 vector dhrint dhxint # # UCBVAX - Gateway to the world # machine vax cpu "VAX780" cpu "VAX750" ident UCBVAX timezone 8 dst maxusers 32 options INET options NS config kernel root on hp swap on hp and rk0 and rk1 config upkernel root on up config hkkernel root on hk swap on rk0 and rk1 controller mba0 at nexus ? controller uba0 at nexus ? disk hp0 at mba? drive 0 disk hp1 at mba? drive 1 controller sc0 at uba? csr 0176700 vector upintr disk up0 at sc0 drive 0 disk up1 at sc0 drive 1 controller hk0 at uba? csr 0177440 vector rkintr disk rk0 at hk0 drive 0 disk rk1 at hk0 drive 1 pseudo-device pty pseudo-device loop pseudo-device imp device acc0 at uba? csr 0167600 vector accrint accxint pseudo-device ether device ec0 at uba? csr 0164330 vector ecrint eccollide ecxint device il0 at uba? csr 0164000 vector ilrint ilcint APPENDIX D. VAX KERNEL DATA STRUCTURE SIZING RULES
Certain system data structures are sized at compile time according to the maximum number of simultaneous users expected, while others are calculated at boot time based on the physical resources present, e.g. memory. This appendix lists both sets of rules and also includes some hints on changing built-in limitations on certain data structures.
The file /sys/conf/param.c contains the definitions of almost all data structures sized at compile time. This file is copied into the directory of each configured system to allow configuration-dependent rules and values to be maintained. (Each copy normally depends on the copy in /sys/conf, and global modifications cause the file to be recopied unless the makefile is modified.) The rules implied by its contents are summarized below (here MAXUSERS refers to the value defined in the configuration file in the ``maxusers'' rule). Most limits are computed at compile time and stored in global variables for use by other modules; they may generally be patched in the system binary image before rebooting to test new values.
20 + 8 * MAXUSERS
36 + MAXUSERS.
(NPROC + 16 + MAXUSERS) + 32
16 * (NPROC + 16 + MAXUSERS) / 10 + 32
16 + NPROC
60 + 12 * MAXUSERS
(MAXUSERS * 9) / 7 + 3
NINODE + (MAXUSERS * NMOUNT) / 4
In addition to the above values, the system page tables (used to map virtual memory in the kernel's address space) are sized at compile time by the SYSPTSIZE definition in the file /sys/vax/vmparam.h. This is defined to be
20 + MAXUSERS
The most important data structures sized at run-time are those used in the buffer cache. Allocation is done by allocating physical memory (and system virtual memory) immediately after the system has been started up; look in the file /sys/vax/machdep.c. The amount of physical memory which may be allocated to the buffer cache is constrained by the size of the system page tables, among other things. While the system may calculate a large amount of memory to be allocated to the buffer cache, if the system page table is too small to map this physical memory into the virtual address space of the system, only as much as can be mapped will be used.
The buffer cache is comprised of a number of ``buffer headers'' and a pool of pages attached to these headers. Buffer headers are divided into two categories: those used for swapping and paging, and those used for normal file I/O. The system tries to allocate 10% of the first two megabytes and 5% of the remaining available physical memory for the buffer cache (where available does not count that space occupied by the system's text and data segments). If this results in fewer than 16 pages of memory allocated, then 16 pages are allocated. This value is kept in the initialized variable bufpages so that it may be patched in the binary image (to allow tuning without recompiling the system), or the default may be overridden with a configuration-file option. For example, the option options BUFPAGES="3200" causes 3200 pages (3.2M bytes) to be used by the buffer cache. A sufficient number of file I/O buffer headers are then allocated to allow each to hold 2 pages each. Each buffer maps 8K bytes. If the number of buffer pages is larger than can be mapped by the buffer headers, the number of pages is reduced. The number of buffer headers allocated is stored in the global variable nbuf, which may be patched before the system is booted. The system option options NBUF="1000" forces the allocation of 1000 buffer headers. Half as many swap I/O buffer headers as file I/O buffers are allocated, but no more than 256.
As distributed, the sum of the virtual sizes of the core-resident processes is limited to 256M bytes. The size of the text segment of a single process is currently limited to 6M bytes. It may be increased to no greater than the data segment size limit (see below) by redefining MAXTSIZ. This may be done with a configuration file option, e.g. options MAXTSIZ="(10*1024*1024)" to set the limit to 10 million bytes. Other per-process limits discussed here may be changed with similar options with names given in parentheses. Soft, user-changeable limits are set to 512K bytes for stack (DFLSSIZ) and 6M bytes for the data segment (DFLDSIZ) by default; these may be increased up to the hard limit with the setrlimit(2) system call. The data and stack segment size hard limits are set by a system configuration option to one of 17M, 33M or 64M bytes. One of these sizes is chosen based on the definition of MAXDSIZ; with no option, the limit is 17M bytes; with an option options MAXDSIZ="(32*1024*1024)" (or any value between 17M and 33M), the limit is increased to 33M bytes, and values larger than 33M result in a limit of 64M bytes. You must be careful in doing this that you have adequate paging space. As normally configured , the system has 16M or 32M bytes per paging area, depending on disk size. The best way to get more space is to provide multiple, thereby interleaved, paging areas. Increasing the virtual memory limits results in interleaving of swap space in larger sections (from 500K bytes to 1M or 2M bytes).
By default, the virtual memory system allocates enough memory for system page tables mapping user page tables to allow 256 megabytes of simultaneous active virtual memory. That is, the sum of the virtual memory sizes of all (completely- or partially-) resident processes can not exceed this limit. If the limit is exceeded, some process(es) must be swapped out. To increase the amount of resident virtual space possible, you can alter the constant USRPTSIZE (in /sys/vax/vmparam.h). Each page of system page tables allows 8 megabytes of user virtual memory.
Because the file system block numbers are stored in page table pg_blkno entries, the maximum size of a file system is limited to 2^24 1024 byte blocks. Thus no file system can be larger than 8 gigabytes.
The number of mountable file systems is set at 20 by the definition of NMOUNT in /sys/h/param.h. This should be sufficient; if not, the value can be increased up to 255. If you have many disks, it makes sense to make some of them single file systems, and the paging areas don't count in this total.
The limit to the number of files that a process may have open simultaneously is set to 64. This limit is set by the NOFILE definition in /sys/h/param.h. It may be increased arbitrarily, with the caveat that the user structure expands by 5 bytes for each file, and thus UPAGES (/sys/vax/machparam.h) must be increased accordingly.
The amount of physical memory is currently limited to 64 Mb
by the size of the index fields in the core-map (/sys/h/cmap.h).
The limit may be increased by following instructions in that file
to enlarge those fields.
APPENDIX E. NETWORK CONFIGURATION OPTIONS
The network support in the kernel is self-configuring according to the protocol support options (INET and NS) and the network hardware discovered during autoconfiguration. There are several changes that may be made to customize network behavior due to local restrictions. Within the Internet protocol routines, the following options set in the system configuration file are supported:
The following options are supported by the Xerox NS protocols: