./_Man_SunOS_4.1.3_html/html8/config.8.html

Manual page for CONFIG(8)

config - build system configuration files

SYNOPSIS

/usr/etc/config [ -fgnp ] [ -o obj_dir ] config_file

DESCRIPTION

config does the preparation necessary for building a new system kernel with make.1 The config_file named on the command line describes the kernel to be made in terms of options you want in your system, size of tables, and device drivers to be included. When you run config, it uses several input files located in the current directory (typically the conf subdirectory of the system source including your config_file). The format of this file is described below.

If the directory named ../config_file does not exist, config will create one. One of config's output files is a makefile which you use with make.1 to build your system.

config must be run from the conf subdirectory of the system source (in a typical Sun environment, from /usr/share/sys/sun{3,3x,4,4c,4m}/conf):

example# /usr/etc/config config_file
Doing a "make depend"
example# cd ../config_file
example# make
 ...lots of output...

While config is running watch for any errors. Never use a kernel which config has complained about; the results are unpredictable. If config completes successfully, you can change directory to the ../config_file directory, where it has placed the new makefile, and use make to build a kernel. The output files placed in this directory include ioconf.c, which contains a description of I/O devices attached to the system; mbglue.s, which contains short assembly language routines used for vectored interrupts, a makefile, which is used by make to build the system; a set of header files (device_name.h) which contain the number of various devices that may be compiled into the system; and a set of swap configuration files which contain definitions for the disk areas to be used for the root file system, swapping, and system dumps.

Now you can install your new kernel and try it out.

OPTIONS

-f: Set up the makefile for fast builds. This is done by building a vmunix.o file which includes all the .o files which have no source. This reduces the number of files which have to be stated during a system build. This is done by prelinking all the files for which no source exists into another file which is then linked in place of all these files when the kernel is made. This makefile is faster because it does not stat the object files during the build.
-g: Get the current version of a missing source file from its SCCS history, if possible.
-n: Do not do the `make depend'. Normally config will do the `make depend' automatically. If this option is used config will print `Don't forget to do a "make depend"' before completing as a reminder.
-p: Configure the system for profiling (see kgmon.8 and gprof.1 This option is only available for systems with full source releases.
-o obj_dir: Use ../obj_dir instead of ../OBJ as the directory to find the object files when the corresponding source file is not present in order to generate the files necessary to compile and link your kernel.

USAGE

Input Grammar

In the following descriptions, a number can be a decimal integer, a whole octal number or a whole hexadecimal number. Hex and octal numbers are specified to config in the same way they are specified to the C compiler, a number starting with 0x is a hex number and a number starting with just a 0 is an octal number.

Comments are begin with a # character, and end at the next NEWLINE. Lines beginning with TAB characters are considered continuations of the previous line. Lines of the configuration file can be one of two basic types. First, there are lines which describe general things about your system:

machine "type": This is system is to run on the machine type specified. Only one machine type can appear in the config file. The legal types for a Sun system are sun3, sun3x, sun4, sun4c, sun4m, and sun386. Note: the double quotes around type are part of the syntax, and must be included.
cpu "type": This system is to run on the CPU type specified. More than one CPU type can appear in the config file.
ident name: Give the system identifier -- a name for the machine or machines that run this kernel. Note: name must be enclosed in double quotes if it contains both letters and digits. Also, note that if name is GENERIC, you need not include the `options GENERIC' clause in order to specify `swap generic'.
maxusers number: The maximum expected number of simultaneously active user on this system is number. This number is used to size several system data structures.
options optlist: Compile the listed options into the system. Options in this list are separated by commas. A line of the form:

: options FUNNY,HAHA

: yields

: -DFUNNY -DHAHA

: to the C compiler. An option may be given a value, by following its name with = (equal sign) then the value enclosed in (double) quotes. None of the standard options use such a value.
: In addition, options can be used to bring in additional files if the option is listed in the files files. All options should be listed in upper case. In this case, no corresponding option.h will be created as it would be using the corresponding pseudo-device method.
config sysname config_clauses...: Generate a system with name sysname and configuration as specified in config-clauses. The sysname is used to name the resultant binary image and per-system swap configuration files. The config_clauses indicate the location for the root file system, one or more disk partitions for swapping and paging, and a disk partition to which system dumps should be made. All but the root device specification may be omitted; config will assign default values as described below.

root: A root device specification is of the form:

: root on xy0d

: If a specific partition is omitted -- for example, if only

: root on xy0

: is specified -- the `a' partition is assumed. When a generic system is being built, no root specification should be given; the root device will be defined at boot time by prompting the console.
swap: To specify a primary swap partition, use a clause of the form:

: swap on partition

: Swapping areas may be almost any size. Partitions used for swapping are sized at boot time by the system; to override dynamic sizing of a swap area the number of sectors in the swap area can be specified in the config file. For example,

: swap on xy0b size 99999

: would configure a swap partition with 99999 sectors. If swap generic or no partition is specified with on, partition b on the root device is used. For dataless clients, use:

: swap on type nfs

dumps: The location to which system dumps are sent may be specified with a clause of the form:

: dumps on xy1

: If no dump device is specified, the first swap partition specified is used. If a device is specified without a particular partition, the `b' partition is assumed. If a generic configuration is to be built, no dump device should be specified; the dump device will be assigned to the swap device dynamically configured at boot time. Dumps are placed at the end of the partition specified. Their size and location is recorded in global kernel variables dumpsize and dumplo, respectively, for use by savecore.8

Device names specified in configuration clauses are mapped to block device major numbers with the file devices.machine, where machine is the machine type previously specified in the configuration file. If a device name to block device major number mapping must be overridden, a device specification may be given in the form:

: major x minor y

The second group of lines in the configuration file describe which devices your system has and what they are connected to (for example, an IPI Channel Adaptor on the VMEbus). These lines have the following format:

: dev_type dev_name at con_dev more_info

dev_type is either controller, disk, tape, device, device-driver, or pseudo-device. These types have the following meanings:

controller: A disk or tape controller.
disk or tape: Devices connected to a controller.
device: Something ``attached'' to the main system bus, like a cartridge tape interface.
device-driver: This declares support for a device of name dev_name. For most devices on desktop SPARCsystems, this is all that is required. See `Desktop SPARCsystem Input Grammar' below for details.
pseudo-device: A software subsystem or driver treated like a device driver, but without any associated hardware. Current examples are the pseudo-tty driver and various network subsystems. For pseudo-devices, more_info may be specified as an integer, that gives the value of the symbol defined in the header file created for that device, and is generally used to indicate the number of instances of the pseudo-device to create.

dev_name is the standard device name and unit number (if the device is not a pseudo-device) of the device you are specifying. For example, idc0 is the dev_name for the first IPI disk controller in a system; st0 names the first SCSI tape controller.

con_dev is what the device you are specifying is connected to. It is either nexus?, a bus type, or a controller. There are several bus types which are used by config and the kernel.

The possible bus types are:

obmem: On board memory
obio: On board io
vme16d16 (vme16): 16 bit VMEbus/ 16 bit data
vme24d16 (vme24): 24 bit VMEbus/ 16 bit data
vme32d16: 32 bit VMEbus/ 16 bit data
vme16d32: 16 bit VMEbus/ 32 bit data
vme24d32: 24 bit VMEbus/ 32 bit data
vme32d32 (vme32): 32 bit VMEbus/ 32 bit data
ipi: IPI pseudo bus (sun4 system only)

All of these bus types are declared to be connected to nexus. The devices are hung off these buses. If the bus is wildcarded, then the autoconfiguation code will determine if it is appropriate to probe for the device on the machine that it is running on. If the bus is numbered, then the autoconfiguation code will only look for that device on machine type N. In general, the VMEbus bus types are always wildcarded.

more_info is a sequence of the following:

csr address: Specify the address of the csr (command and status registers) for a device. The csr addresses specified for the device are the addresses within the bus type specified.
: The csr address must be specified for all controllers, and for all devices connected to a main system bus.
drive number: For a disk or tape, specify which drive this is.
flags number: These flags are made available to the device driver, and are usually read at system initialization time.
priority level: For devices which interrupt, specify the interrupt level at which the device operates.
vector intr number [ intr number . . . ]: For devices which use vectored interrupts on VMEbus systems, intr specify the vectored interrupt routine and number the corresponding vector to be used (0x40-0xFF).

A ? may be substituted for a number in two places and the system will figure out what to fill in for the ? when it boots. You can put question marks on a con_dev (for example, at virtual `?'), or on a drive number (for example, drive `?'). This allows redundancy, as a single system can be built which will boot on different hardware configurations.

The easiest way to understand config files it to look at a working one and modify it to suit your system. Good examples are provided in [a manual with the abbreviation INSTALL].

Desktop SPARCsystem Input Grammar

Desktop SPARCsystems' usage is a good deal simpler than what is described above, due primarily to information provided by the PROM monitor that obviates the specific descriptions of csr and vector values. There is no need to declare a nexus, or a controller: all primary controllers and main I/O units are simply described by the device-driver keyword. That is, a complete specification of all UART controllers (see zs.4s for a desktop SPARCsystem is done by declaring:

: device-driver zs

An additional keyword has been introduced for desktop SPARCsystems to describe SCSI disks and tapes that may be resident on the system: scsibus. Its usage is:

: scsibusN at device-driver

which declares that there exists a SCSI bus supported by a device-driver previously declared.

After specifying that there is a SCSI bus, you then can specify disks and tapes that may be connected to this SCSI bus. For example, the declaration

: disk sd0 at scsibus0 target 3 lun 0

states that there may be a disk (in this example, sd0) attached to scsibus0, at SCSI Target ID 3, SCSI Logical unit 0.

SPARCsystem 600MP Series Input Grammar

SPARCsystem 600MP series machines have a combination of both the common input grammar (described above in `Input Grammar'), and the desktop SPARCsystem grammar (described above in `Desktop SPARCsystem Input Grammar'). For VMEbus devices, such as IPI, the grammar is similar to the common grammar. For sbus devices, such as SCSI, the grammar is similar to that of desktop SPARCsystems.

FILES

Files in /usr/share/sys/sun{3,3x,4,4c,4m}/conf which may be useful for developing the config_file used by config are:

GENERIC: The generic configuration file for a given Sun system. This file contains all possible device description lines for the particular architecture.
GENERIC_SMALL: A reduced generic configuration file for certain vanilla configurations. Check the comments at the top of the file for specific architectures and devices supported.
DLmodel, SDSTmodel, etc.: Many of the architectures supply template configuration files trimmed to support only certain devices or environments (like diskless clients, standalone systems with SCSI disks and tape, and so on). Comments at the top of these files specify models and devices supported.
README: File describing how to make a new kernel.

As shipped from Sun, the files used by /usr/etc/config as input are in the /usr/include/sys/conf directory:

config_file: System-specific configuration file
Makefile.src: Generic prototype makefile for Sun-[34] systems
files: List of common files required to build a basic kernel
devices: Name to major device mapping file for Sun-[34] systems

/usr/etc/config places its output files in the ../config_file directory:

mbglue.s: Short assembly language routines used for vectored interrupts
ioconf.c: Describes I/O devices attached to the system
makefile: Used with make.1 to build the system
device_name.h: a set of header files (various device_name's) containing devices which can be compiled into the system