Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
master(4)		   Kernel Interfaces Manual		     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  mod-
       ules.   Other  kernel  configuration tools also use the master files to
       obtain information about	the traditional	or modular kernel modules  in-
       stalled	on  the	system.	 Installed master files	should not be modified
       by system administrators.

       Master files are	of two types:

       o   A can carry information of one or more kernel modules (like	device
	   drivers)  or	subsystems, and	can carry other	system-wide configura-
	   tion	information like system	tunable	parameters.

       o   A 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.  Dy-
	   namically  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 encoun-
       tered. Lines beginning with an asterisk are  comments.

   Traditional Master File
       The following table lists the section keywords for the traditional mas-
       ter  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 driver specification
	      Context Dependent	I/O table
	      List of drivers with installation	functions
	      Dynamic block and	character major	numbers
	      Driver alias table
	      Tunable parameters
	      Driver-to-driver dependency table
	      Library location of driver table
	      Required/optional	library	table
	      Subsystems requiring
	      STREAMS synchronization level table
	      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 ex-
       pressed 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 section.

       Software	drivers	are defined using five fields defined as follows:

       Field_1	 Device	name, used in the user-specified system_file (8	 char-
		 acters	maximum).

       Field_2	 Handler  name,	 used by the kernel to prefix routines such as
		 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 fol-
		 lowing	seven bits.

		 STREAMS module
		 STREAMS driver
		 I/O card or pseudo driver
		 Allow only one	specification of driver
		 Required device (included in all systems)
		 Block device
		 Character device

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

		 Turn off map buffer to	kernel flag
		 Set driver is multiprocessor capable flag
		 Set STREAMS clone major device	flag
		 Set STREAMS System V release 3	style open flag
		 Set STREAMS System V release 4	style open flag
		 Autochanger	routine	exists
		 handler exists	(Series	700 only)
		 handler exists
		 handler exists
		 routine exists
		 handler exists
		 handler exists
		 handler exists
		 handler exists
		 handler exists
		 handler exists
		 handler exists
		 Set device	routine	called on all closes flag

       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 mini-
       mal 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 re-
       served for drivers whose	major numbers are assigned dynamically.

       Field_1	 or

       Field_2	 A major number	or a range of major numbers.  A	range is spec-
		 ified as 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	statement  in  (20  characters
		 maximum).  In	previous  releases, the	statement in which the
		 parameter name	was used, was in

       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  ob-
       ject 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 re-
       quired 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 IDENTIFIER statements in
       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  de-
       tailed 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 list.)

       Field_3	 (Optional) Additional STREAMS synchronization information.

   Modular Master File
       The  following section keywords and purposes are	used only in the modu-
       lar master files.

	      Section keyword		    Section purpose

	      File format version
	      Load capability of module
	      Interface	used by	module
	      Module type specific information

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

	      Section keyword		    Section purpose

	      Dependency to other kernel modules.
	      Same as			    section.
	      Same as

       For  DLKM  modules, section information is used when the	module is con-
       figured 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 subsec-
       tions listed from here on.  A version 1 master file cannot contain  the
       keyword in the section described	below.

       Field_1	 Version number. (decimal number)

       Example

   $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

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

       Example

       For  version 2 master files, this section may contain the optional key-
       word 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:

       If  the	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 run-
       time (but not at	phase 2	of the boot sequence).

   $INTERFACE Section
       List of used interfaces by kernel modules.

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

       Field_1	 Interface name. (string)

       Example

   $TYPE Section
       Module type and type specific information list.

       Field_1	 Kernel	module name.

       Field_2	 Module	type name.

		 are valid.

       Fields 3	- 6 contain module type	specific fields	for the	the  following
       types: and

       Field_3	 Class name.

       Field_4	 Flags.

		 character device driver.

		 block device driver.

		 pseudo	driver.

		 supports scanning.

		 MP capable driver.

		 Save information to ioconfig.

       Field_5	 block device major number.

       Field_6	 character device major	number.

       Example

EXAMPLES
       The  following  entry  in the section will enable the kernel to dynami-
       cally assign block  and/or  character  major  number(s)	for  a	custom
       driver,

FILES
       Traditional and modular master configuration files

SEE ALSO
       kminstall(1M), config(1M), kmsystem(1M),	kmtune(1M), system(4).

								     master(4)

NAME | DESCRIPTION | EXAMPLES | FILES | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=master&sektion=4&manpath=HP-UX+11.22>

home | help