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

FreeBSD Manual Pages

  
 
  

home | help
system(4)		   Kernel Interfaces Manual		     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)  de-
       scribe planned configuration information	used by	the config(1M) command
       to configure and	build a	kernel and/or kernel modules.  The planned at-
       tribute	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:

       o   The	traditional  system  file lists	the traditional	kernel modules
	   scheduled to	be configured during the next kernel build.  In	 addi-
	   tion,  the traditional system file contains planned values for sys-
	   tem tunable parameters, and other system-wide configuration	infor-
	   mation.

       o   A  modular  system  file  carries planned configuration information
	   about a single kernel module.  Such a system	file is	part of	a mod-
	   ularly  packaged module's component set, and	must be	installed onto
	   a system via	the kminstall(1M) command.  Dynamically	loadable  mod-
	   ules	must be	packaged modularly, and	must have a corresponding mod-
	   ular	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 ker-
       nel  configuration.  This list should only be modified using the	kmsys-
       tem(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 de-
	    vice tables	in the files in	the directory, [See  master(4).]   For
	    example,  selects  the  driver  for	 SCSI disk drives, selects the
	    driver for SCSI tape drives, and selects the NFS  subsystem.   To-
	    gether,  the files in contain a complete list of configurable ker-
	    nel	modules	(devices, cards, subsystems, and pseudo-drivers).

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

       o   define the swap device

       o   define the dump device(s)

       o   provide a mapping of	a driver to a hardware path

       o   define status and values of selected	system parameters.

       Lines are constructed as	indicated below	for each category.

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

	    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 re-
		      mainder 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 re-
		      served area, or whether blocks is	bumped by the size  of
		      the  unused area,	resulting in the swap area being adja-
		      cent to the tail of the device.

	    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,
		 would put the swap area on section 3.

	    Configure swap on a	logical	volume.

	    Configure the kernel with no swap device.

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

	    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 of-
		      fered for	backwards compatibility	purposes.  For example
		      would put	the dump area at section 3.

	    Configure dump on a	logical	volume.

	    Configure the kernel with no dump device.

       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.

	    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.

       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 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	semaphores and
	    shared memory features.  If	and/or 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 in-
	    cluded, the	parameters listed below	can be modified:

   Modular System File
       Modular system files contain the	configurable information  about	 modu-
       larly  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 km-
       tune(1M)	system administration commands should be used to  retrieve  or
       set this	information.

       Each file consists of one mandatory and four optional sections.

		   The line starting with
	    indicates  the version number for the file format.	Version	is de-
	    fined as a decimal number and starts from one.

	    The	specified version must match the version of the	module's  cor-
	    responding master file.

	    A  version	2 system file may contain all the sections listed from
	    here on.  A	version	1 system file cannot contain the  section  de-
	    scribed below.

	    Format is:

	    Example:

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

	    Format is:

	    Example:

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

	    If	the  field  is or the 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 section, then
	    the	system file should not have one	either.

	    Format is:

	    Example:

		   The line starting with
	    takes one field that specifies the planned loading	phase  of  the
	    module.   Planned loading phase is specified as one	of the follow-
	    ing: or

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

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

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

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

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

	    Absence  of	this section indicates that the	module will be config-
	    ured to be loaded on demand	 or  by	 the  auto  loading  mechanism
	    (equivalent	to defining ).

	    Format is:

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

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

       The keywords 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
       HP-UX system description	file (traditional system file)

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

								     system(4)

NAME | DESCRIPTION | FILES | SEE ALSO

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

home | help