master(4)

NAME

master — master kernel configuration information

DESCRIPTION

The distributed set of traditional and modular master files describe configuration information supplied by kernel developers as part of the HP-UX operating system. A master file contains information used by the config(1M) command to configure and build a kernel and/or kernel modules. Other kernel configuration tools also use the master files to obtain information about the traditional or modular kernel modules installed on the system. Installed master files should not be modified by system administrators.

Master files are of two types:

A traditional master file can carry information of one or more kernel modules (like device drivers) or subsystems, and can carry other system-wide configuration information like system tunable parameters.
A modular master file carries information about a single kernel module. Such a master 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 master and a corresponding modular system(4) file.

Each section of a master file begins with a line containing a $ in column one followed by a section keyword. The section continues to the end of the file or until a line containing only three $ characters is encountered. Lines beginning with an asterisk (*) are comments.

Traditional Master File

The following table lists the section keywords for the traditional master file and their purpose. Note that some of the section keywords may also be used for the modular master file described later:

Section keyword: Section purpose
$DEVICE: Device driver specification
$CDIO: Context Dependent I/O table
$DRIVER_INSTALL: List of drivers with installation functions
$DYN_MAJOR: Dynamic block and character major numbers
$ALIAS: Driver alias table
$TUNABLE: Tunable parameters
$DRIVER_DEPENDENCY: Driver-to-driver dependency table
$DRIVER_LIBRARY: Library location of driver table
$LIBRARY: Required/optional library table
$SUBSYSTEMS_DEFINE: Subsystems requiring #defines
$STREAMS_SYNC_LEVEL: STREAMS synchronization level table
$STREAMS_DVR_SYNC: STREAMS driver and module synchronization table

Each section consists of text fields separated by space and/or tab characters and is described separately below. Bit mask fields are expressed as hexadecimal values which are constructed by computing the logical OR of the component bit values.

$DEVICE Section

NOTE: This section is provided for compatibility with previous HP-UX releases. New drivers should be added to the $DRIVER_INSTALL section.

Software drivers are defined using five fields defined as follows:

Field_1

Device name, used in the user-specified system_file (8 characters maximum).

Field_2

Handler name, used by the kernel to prefix routines such as lp_write and others (8 characters maximum).

Field_3

Driver characteristics, which are specified by computing the logical OR using the hexadecimal bit mask value of the following seven bits.

0x40: STREAMS module
0x20: STREAMS driver
0x10: I/O card or pseudo driver
0x08: Allow only one specification of driver
0x04: Required device (included in all systems)
0x02: Block device
0x01: Character device

Field_4

Functions for the device, specified by creating a bit mask using the following bits:

0x100000: Turn off map buffer to kernel flag (C_MAP_BUFFER_TO_KERNEL)
0x010000: Set driver is multiprocessor capable flag (C_MGR_IS_MP)
0x008000: Set STREAMS clone major device flag (C_CLONESMAJOR)
0x004000: Set STREAMS System V release 3 style open flag (SVR3_OPEN)
0x002000: Set STREAMS System V release 4 style open flag (SVR4_OPEN)
0x001000: Autochanger mount routine exists
0x000800: option1 handler exists (Series 700 only)
0x000400: dump handler exists
0x000200: size handler exists
0x000100: link routine exists
0x000080: open handler exists
0x000040: close handler exists
0x000020: read handler exists
0x000010: write handler exists
0x000008: ioctl handler exists
0x000004: select handler exists
0x000002: seltru handler exists
0x000001: Set device close routine called on all closes flag (C_ALLCLOSES)

Field_5

Block major device number if a block-type device; otherwise -1.

Field_6

Character major device number if a character-type device; otherwise -1.

$CDIO Section

CDIO (Context Dependent I/O) list. List of I/O modules specific to the bus and/or driver environment, and whether they are required in a minimal system.

Field_1: CDIO name.
Field_2: 1 if the CDIO is required for a minimal system; otherwise 0.

$DYN_MAJOR Section

Dynamic major numbers. A range of block and character major numbers reserved for drivers whose major numbers are assigned dynamically.

Field_1: block or char.
Field_2: A major number or a range of major numbers. A range is specified as lo_major_num- hi_major_num.

$DRIVER_INSTALL Section

Driver install section is a list of drivers, shown with their block and character major numbers

Field_1: Driver name.
Field_2: Block major device number if a block-type device; otherwise -1.
Field_3: Character major device number if a character-type device; otherwise -1.
Field_4: 1 if the driver is required for a minimal system; otherwise 0.

$ALIAS Section

Aliases for names are defined as follows:

Field_1: Alias name => product number (8 characters maximum)
Field_2: Device name (8 characters maximum)

$TUNABLE Section

Tunable parameters are defined as follows:

Field_1: Parameter name as used in the user-specified system_file (20 characters maximum).
Field_2: Parameter name as used in the #define statement in tune.h (20 characters maximum). In previous releases, the #define statement in which the parameter name was used, was in conf.c.
Field_3: Default value for the parameter (60 characters maximum).
Field_4: Minimum value for the parameter (60 characters maximum).

$DRIVER_DEPENDENCY Section

List of drivers and the other drivers they depend on.

Field_1: Dependent driver.
Field_2-N: Name of supporting drivers or CDIO's.

$DRIVER_LIBRARY Section

List of drivers and the library or libraries containing the driver object code.

Field_1: Driver name.
Field_2-N: Name of libraries containing driver code.

$LIBRARY Section

Library list. List of object code libraries and whether they are required is a minimal system.

Field_1: Library name.
Field_2: 1 if the library is required for a minimal system; otherwise 0.

$SUBSYSTEMS_DEFINE Section

List of subsystems and/or drivers that require #define IDENTIFIER statements in conf.c. If needed, the identifier will be converted to upper case.

Field_1: Subsystem/driver name.
Field_2: (Optional) Name of identifier to define. If this field is not present, the identifier will be Field_1 in upper case.

$STREAMS_SYNC_LEVEL Section

List of possible STREAMS synchronization levels. Please refer to the documentation that accompanied the STREAMS/UX product for a more detailed description of this table and STREAMS synchronization levels.

Field_1: Synchronization level.

$STREAMS_DVR_SYNC Section

List of STREAMS modules and drivers and the synchronization levels that they require. Please refer to the documentation that accompanied the STREAMS/UX product for more information about this table.

Field_1: Driver or module name.
Field_2: Synchronization level. (Must be present in a $STREAM_SYNC_LEVEL list.)
Field_3: (Optional) Additional STREAMS synchronization information.

Modular Master File

The following section keywords and purposes are used only in the modular master files.

Section keyword: Section purpose
$VERSION: File format version
$LOADABLE: Load capability of module
$INTERFACE: Interface used by module
$TYPE: Module type specific information

If required, kernel module master files may use the following section keywords and purposes described earlier.

Section keyword: Section purpose
$DRIVER_DEPENDENCY: Dependency to other kernel modules.
$TUNABLE: Same as $TUNABLE section.
$DRIVER_INSTALL: Same as $DRIVER_INSTALL.

For DLKM modules, $DRIVER_INSTALL section information is used when the module is configured to be linked into the kernel statically. [See kmsystem(1M).] The first field of this section indicates the module_name.

Each section consists of text fields separated by space and/or tab characters and is described separately below.

$VERSION Section

File format version.

Indicates the version number for the modular master file format. The version number is a decimal number and starts from one. The specified version must match the version of the module's corresponding system(4) file.

A version 2 master file may contain all the file sections and subsections listed from here on. A version 1 master file cannot contain the phases keyword in the $LOADABLE section described below.

Field_1: Version number. (decimal number)

Example

$VERSION 
2 
$$$ 

$LOADABLE Section

Load capability of a kernel module.

If the section exists, the module supports dynamic loading. Otherwise it can be only be configured to be statically linked into the kernel.

Example

$LOADABLE 
$$$ 

If the module depends on a kernel stub, the keyword stub should be specified within the section.

Example

$LOADABLE 
stub 
$$$ 

For version 2 master files, this section may contain the optional keyword phases followed by a field that specifies the supported loading phases of the module. The supported loading phases are specified by computing the logical OR using the hexadecimal bit mask value of the following 3 bits:

0x01	Phase 1 of the boot sequence (BOOT1) 
0x02	Phase 2 of the boot sequence (BOOT2) 
0x04	Runtime (RUN) 

If the phases keyword is missing, supported loading phases is assumed to be runtime only (0x04).

Example

The following specifies that the module is capable of dynamic loading, and is capable of loading at phase 1 of the boot sequence and at runtime (but not at phase 2 of the boot sequence).

$LOADABLE 
phases 0x05 
$$$ 

$INTERFACE Section

List of used interfaces by kernel modules.

Note: This is for future HP-UX capabilities. Currently only base should be specified in Field 1. When base is specified, interface enforcement and version control will be exempted and the module will need to be maintained by its developer to be in synchronization with the kernel or other components.

Field_1: Interface name. (string)

Example

$INTERFACE 
base 
$$$ 

$TYPE Section

Module type and type specific information list.

Field_1

Kernel module name.

Field_2

Module type name.

wsio_class, wsio_intfc, streams_mod, streams_drv, misc are valid.

Fields 3 - 6 contain module type specific fields for the the following types: wsio_class, wsio_intfc and streams_drv.

Field_3

Class name.

Field_4

Flags.

c: character device driver.
b: block device driver.
p: pseudo driver.
s: supports scanning.
m: MP capable driver.
i: Save information to ioconfig.

Field_5

block device major number.

Field_6

character device major number.

Example

$TYPE 
wsio stape tape c -1 203 
$$$ 

EXAMPLES

The following entry in the $DRIVER_INSTALL section will enable the kernel to dynamically assign block and/or character major number(s) for a custom driver, mydriver.

 mydriver     -1     -1     0 

FILES

/usr/conf/master.d: Traditional and modular master configuration files

master(4)

Technical documentation

» Table of Contents

» Index

NAME

DESCRIPTION

Traditional Master File

$DEVICE Section

$CDIO Section

$DYN_MAJOR Section

$DRIVER_INSTALL Section

$ALIAS Section

$TUNABLE Section

$DRIVER_DEPENDENCY Section

$DRIVER_LIBRARY Section

$LIBRARY Section

$SUBSYSTEMS_DEFINE Section

$STREAMS_SYNC_LEVEL Section

$STREAMS_DVR_SYNC Section

Modular Master File

$VERSION Section

$LOADABLE Section

$INTERFACE Section

$TYPE Section

EXAMPLES

FILES

SEE ALSO