system(4)

NAME

system — system description configuration files

DESCRIPTION

The HP-UX system description file (traditional system file) and the set of distributed kernel module system files (modular system files) describe planned configuration information used by the config(1M) command to configure and build a kernel and/or kernel modules. The planned attribute values saved in the traditional and modular system files are used to tailor the system and kernel before a call to config(1M). Other kernel configuration tools also use the system files to obtain information about the traditional or modular kernel modules installed on the system.

System files are of two types:

The traditional system file lists the traditional kernel modules scheduled to be configured during the next kernel build. In addition, the traditional system file contains planned values for system tunable parameters, and other system-wide configuration information.
A modular system file carries planned configuration information about a single kernel module. Such a system file is part of a modularly packaged module's component set, and must be installed onto a system via the kminstall(1M) command. Dynamically loadable modules must be packaged modularly, and must have a corresponding modular system file and a corresponding modular master(4) file.

HP-UX System Description File (Traditional System File)

The first part of the traditional system file is used to list all of the traditional kernel modules (including device drivers and pseudo-drivers) that are scheduled to be configured during the next whole kernel configuration. This list should only be modified using the kmsystem(1M) command.

Each line has the following format:

traditional_module: where traditional_module is the traditional kernel module name as it appears in the alias tables, driver install tables or the device tables in the files in the directory, /usr/conf/master.d. [See master(4).] For example, scsi selects the driver for SCSI disk drives, scsitape selects the driver for SCSI tape drives, and nfs selects the NFS subsystem. Together, the files in /usr/conf/master.d contain a complete list of configurable kernel modules (devices, cards, subsystems, and pseudo-drivers).

The optional second part of the traditional system file is used to:

define the swap device
define the dump device(s)
provide a mapping of a driver to a hardware path
define status and values of selected system parameters.

Lines are constructed as indicated below for each category.

(1) Swap device specification

No more than one swap specification is allowed. If a swap specification is not given, the system will be configured to swap on the root device at the end of the filesystem.

swap hw_path offset [blocks]

Configure the swap device location and its size as specified. Arguments are interpreted as follows:

hw_path: The hardware path representing the device to configure as the swap device or the string default may be used to indicate using the root device.
offset: The swap area location. Boundaries are located at 1K-byte intervals. A negative value specifies that a file system is expected on the device. At boot-up, the super block is read to determine the exact size of the file system, and this value is put in offset. If the swap device is auto-configured, this is the mechanism used. If the super block is invalid, the entry will be skipped so that a corrupted super block will not later cause the entire file system to be corrupted by configuring the swap area on top of it. A positive or zero value for offset specifies the minimum area that must be reserved. Zero means to reserve no area at the head of the device. A zero value implies that there is no file system on the device.
blocks: The number (in decimal) of 1K-byte disk blocks in the swap area. For this swap device specification, only the blocks parameter is optional. Zero is the default for auto-configuration. If blocks is zero, the entire remainder of the device is automatically configured in as swap area. If blocks is non-zero, its absolute value is treated as an upper bound for the size of the swap area. Then, if the swap area size has actually been cut back, the sign of blocks determines whether blocks remains as is, resulting in the swap area being adjacent to the reserved area, or whether blocks is bumped by the size of the unused area, resulting in the swap area being adjacent to the tail of the device.

swap hw_path options

Configure the swap device at the location specified using the options specified. The hw_path argument is interpreted as it is in the previous example.

The options field is used to specify a section. It is only offered for backwards compatibility purposes. For example, s3 would put the swap area on section 3.

swap lvol

Configure swap on a logical volume.

swap none

Configure the kernel with no swap device.

(2) Dump device(s) specification

One or more dump specifications are allowed. If a dump specification is not given, then the primary swap area will be used.

dump hw_path [options]

Configure the dump device location and its size as specified. Arguments are interpreted as follows:

hw_path: The hardware path representing the device to configure as a dump device or the string default may be used to indicate using the primary swap area.
options: This field is used to specify a section. It is only offered for backwards compatibility purposes. For example s3 would put the dump area at section 3.

dump lvol

Configure dump on a logical volume.

dump none

Configure the kernel with no dump device.

(3) Device driver to hardware path

One or more driver to hardware path specifications is allowed. If a driver statement is provided, the specified software module is forced into the kernel I/O system at the given hardware path. This can be used to make the system recognize a device that could not be recognized automatically.

driver hw_path driver_name

Bind the driver into the kernel I/O system at the given hardware path. Arguments are interpreted as follows:

hw_path: The hardware path representing the device to bind the software with.
driver_name: The name of the software module to bind into the kernel at the specified hardware path.

(4) System kernel tunable parameters

This section contains the values (other than default) of kernel tunable parameters that will be used for the next kernel configuration. Kernel tunable parameters and their default values are defined in the master files under /usr/conf/master.d. These parameters should only be added, deleted, or modified via the kmtune(1M) command.

Each line contains two fields. The first field can contain up to 20 characters; the second field up to 60 characters. Each line is independent, optional, and written in the following format:

 parameter_name      number or formula 

Interprocess communication consists of messages (mesg), semaphores (sema) and shared memory (shmem) features. If mesg, sema, and/or shmem are specified as 0, the kernel code for these features is not included. If they are specified as 1, the kernel code is included; this is the default. The features can be specified independent of each other. If the code is included, the parameters listed below can be modified:

mesg        1 msgmap msgmax msgmnb msgmni msgseg msgssz msgtql sema        1 semaem semmap semmni semmns semmnu semume semvmx shmem       1 shmall smbrk shmmax shmmin shmmni shmseg

 number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula   number or formula 

Modular System File

Modular system files contain the configurable information about modularly packaged kernel modules and are installed via the kminstall(1M) command in the locations where config(1M) expects them. These files should never be modified manually; instead, the kmsystem(1M) and kmtune(1M) system administration commands should be used to retrieve or set this information.

Each file consists of one mandatory and four optional sections.

$VERSION: (Mandatory section)

The line starting with $VERSION indicates the version number for the file format. Version is defined as a decimal number and starts from one.

The specified version must match the version of the module's corresponding master file.

A version 2 system file may contain all the sections listed from here on. A version 1 system file cannot contain the $LOADPHASE section described below.

Format is:

$VERSION version_number

Example:

$VERSION 2 

$CONFIGURE:

The line starting with $CONFIGURE indicates whether the module should be configured. If the second field is y, the module will be configured during the next kernel or module configuration. If the field is n, or the $CONFIGURE section is missing from the system file, the module will not be configured during the next kernel or module configuration.

Format is:

$CONFIGURE 
{y|n}

Example:

$CONFIGURE y

$LOADABLE:

The line starting with $LOADABLE indicates the planned linkage of the module. If the second field is y, the module will be configured as a dynamically loadable module during the next kernel or modules configuration.

If the field is n, or the $LOADABLE section is missing from the system file, the module will be statically linked into the kernel during the next whole kernel configuration.

If the master file for the module does not have a $LOADABLE section, then the system file should not have one either.

Format is:

$LOADABLE 
{y|n}

Example:

$LOADABLE y

$LOADPHASE:

The line starting with $LOADPHASE takes one field that specifies the planned loading phase of the module. Planned loading phase is specified as one of the following: 1, 2, i, or a.

A value equal to 1 (BOOT1), indicates that once the module is configured and registered with the kernel, the module should be loaded during phase 1 of the kernel boot sequence.

A value equal to 2 (BOOT2), indicates that once the module is configured and registered with the kernel, the module should be loaded during phase 2 of the kernel boot sequence.

A value equal to i (INIT), indicates that once the module is configured and registered with the kernel, the module should be loaded during the init process.

A value equal to a (AUTO), indicates that the module is not to be loaded upon system reboot, but should remain ready to load on demand, or by the DLKM auto loading mechanism (load on device access).

Once the module is configured and registered with the kernel, the configured loading phase can be changed dynamically using the kmadmin(1M) command, -b option.

Absence of this section indicates that the module will be configured to be loaded on demand or by the auto loading mechanism (equivalent to defining $LOADPHASE a).

Format is:

$LOADPHASE 
{a|1|2
|i}

For example, the following definition specifies that the module will be configured to be loaded in phase 2 of the boot sequence:

$LOADABLE y
$LOADPHASE 2

$TUNABLE

The section between the lines starting with $TUNABLE, and ending with $$$ indicates tunable parameters of the module.

The keywords $VERSION, $CONFIGURE, and so on, must start at the beginning of the line without white space or tabs. Field separators can be single white spaces, tabs, or a combination of both.

Lines starting with an asterisk (*) are comment lines.

FILES

/stand/system: HP-UX system description file (traditional system file)

system(4)

Technical documentation

» Table of Contents

» Index

NAME

DESCRIPTION

HP-UX System Description File (Traditional System File)

Modular System File

FILES

SEE ALSO