DESCRIPTION
A master file contains sections of information in a form suitable for
config,
enabling it to create a kernel configuration file.
Master files are found in the directory
/usr/conf/master.d.
Master files are of two types:
A kernel master file is of the type which usually carries information on several drivers/subsystems.
A kernel module master file carries information on an individual module.
Such master files are named after the module to which they belong
and are installed onto a system via
kminstall.
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.
Kernel Master File
The following table lists the section keywords for the kernel master file
and their purpose. Note that some of the section keywords may
also be used for the kernel module 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 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
cs80_read,
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.
Kernel Module Master File
The following section keywords and purposes are used only in the kernel
module 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 kernel modules,
$DRIVER_INSTALL
section information is used to link the kernel module into the kernel
statically. The first field of this section indicates the module_name.
Each section consists of text fields separated by space and tab
characters and is described separately below.
$VERSION Section
Format version.
Format version starts from one.
- Field_1
Version number. (decimal number)
Example
$LOADABLE Section
Capability of a kernel module.
If the section exists, the module is dynamically loadable.
Otherwise it can be only statically linked into the kernel.
Boot device related kernel modules should not supply the section.
Kernel module without
$LOADABLE
section cannot be configured as dynamically loadable module.
Example
If the module is using stub, keyword
stub
should be specified within the section.
Example
$INTERFACE Section
List of used interfaces by kernel modules.
NOTE:
base
may be specified in Field 1 alternatively. If
base
is specified, interface enforcement and version control will be exempted
and module will need to be maintained by its developer to be in synchronization
with kernel or other components.
- Field_1
Interface name. (string)
- Field_2
Version name. (string)
Example
$INTERFACE
wsio2 1
xyz 4
$$$
$TYPE Section
Module type and type specific information list.
- Field_1
Kernel module name.
- Field_2
Module type name.
wsio2_class,
wsio2_intfc,
wsio_class,
wsio_intfc,
streams_mod,
streams_drv,
misc
are valid.
Fields 3 - 6 contains module type specific fields for these types;
wsio2_class,
wsio2_intfc,
wsio_class,
wsio_intfc,
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
wsio2 stape2 tape c -1 203
$$$
