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

FreeBSD Manual Pages


home | help
CONFIG(8)		    System Manager's Manual		     CONFIG(8)

       config -	build system configuration files

       /usr/etc/config [ -fgnp ] [ -o obj_dir ]	config_file

       config  does the	preparation necessary for building a new system	kernel
       with make(1).  The config_file named on the command line	describes  the
       kernel  to be made in terms of options you want in your system, size of
       tables, and device drivers to be	included. When you run config, it uses
       several	input  files  located  in the current directory	(typically the
       conf subdirectory of the	system	source	including  your	 config_file).
       The format of this file is described below.

       If  the directory named ../config_file does not exist, config will cre-
       ate one.	 One of	config's output	files is a makefile which you use with
       make(1) to build	your system.

       config  must be run from	the conf subdirectory of the system source (in
       a typical Sun environment, from /usr/share/sys/sun{3,3x,4,4c,4m}/conf):
	      example# /usr/etc/config config_file
	      Doing a "make depend"
	      example# cd ../config_file
	      example# make
	       ...lots of output...

       While config is running watch for any errors.  Never use	a kernel which
       config  has complained about; the results are unpredictable.  If	config
       completes successfully, you can change directory	to the	../config_file
       directory,  where it has	placed the new makefile, and use make to build
       a kernel.  The output files placed in this directory include  ioconf.c,
       which  contains	a  description	of I/O devices attached	to the system;
       mbglue.s, which contains	short assembly language	routines used for vec-
       tored  interrupts,  a makefile, which is	used by	make to	build the sys-
       tem; a set of header files (device_name.h) which	contain	the number  of
       various devices that may	be compiled into the system; and a set of swap
       configuration files which contain definitions for the disk areas	to  be
       used for	the root file system, swapping,	and system dumps.

       Now you can install your	new kernel and try it out.

       -f     Set  up the makefile for fast builds. This is done by building a
	      vmunix.o file which includes all the  .o	files  which  have  no
	      source.	This  reduces  the  number  of	files which have to be
	      stated during a system build.  This is done  by  prelinking  all
	      the  files for which no source exists into another file which is
	      then linked in place of all these	files when the kernel is made.
	      This  makefile  is  faster  because  it does not stat the	object
	      files during the build.

       -g     Get the current version of a missing source file from  its  SCCS
	      history, if possible.

       -n     Do  not do the `make depend'.  Normally config will do the `make
	      depend' automatically.  If this option is	used config will print
	      `Don't  forget to	do a "make depend"' before completing as a re-

       -p     Configure	the system for profiling (see kgmon(8) and  gprof(1)).
	      This  option  is only available for systems with full source re-

       -o obj_dir
	      Use ../obj_dir instead of	../OBJ as the directory	 to  find  the
	      object  files  when the corresponding source file	is not present
	      in order to generate the files necessary	to  compile  and  link
	      your kernel.

   Input Grammar
       In  the	following  descriptions,  a number can be a decimal integer, a
       whole octal number or a whole hexadecimal number.  Hex and  octal  num-
       bers  are specified to config in	the same way they are specified	to the
       C compiler, a number starting with 0x is	a  hex	number	and  a	number
       starting	with just a 0 is an octal number.

       Comments	 are  begin  with  a # character, and end at the next NEWLINE.
       Lines beginning with TAB	characters are considered continuations	of the
       previous	line.  Lines of	the configuration file can be one of two basic
       types.  First, there are	lines which describe general things about your

       machine "type"
	      This  is	system	is to run on the machine type specified.  Only
	      one machine type can appear in the config	file.  The legal types
	      for  a  Sun  system  are	sun3,  sun3x,  sun4, sun4c, sun4m, and
	      sun386.  Note: the double	quotes around type  are	 part  of  the
	      syntax, and must be included.

       cpu "type"
	      This  system is to run on	the CPU	type specified.	 More than one
	      CPU type can appear in the config	file.

       ident name
	      Give the system identifier -- a name for the machine or machines
	      that  run	 this  kernel.	 Note: name must be enclosed in	double
	      quotes if	it contains both letters and digits.  Also, note  that
	      if  name	is GENERIC, you	need not include the `options GENERIC'
	      clause in	order to specify `swap generic'.

       maxusers	number
	      The maximum expected number of  simultaneously  active  user  on
	      this system is number.  This number is used to size several sys-
	      tem data structures.

       options optlist
	      Compile the listed options into the  system.   Options  in  this
	      list are separated by commas.  A line of the form:

		     options FUNNY,HAHA



	      to the C compiler.  An option may	be given a value, by following
	      its name with = (equal sign) then	the value enclosed in (double)
	      quotes.  None of the standard options use	such a value.

	      In addition, options can be used to bring	in additional files if
	      the option is listed in the files	files.	All options should  be
	      listed  in  upper	case.  In this case, no	corresponding option.h
	      will be created as it would be using the	corresponding  pseudo-
	      device method.

       config sysname config_clauses...
	      Generate	a system with name sysname and configuration as	speci-
	      fied in config-clauses.  The sysname is used to name the	resul-
	      tant  binary image and per-system	swap configuration files.  The
	      config_clauses indicate the location for the root	 file  system,
	      one  or more disk	partitions for swapping	and paging, and	a disk
	      partition	to which system	dumps should be	 made.	 All  but  the
	      root device specification	may be omitted;	config will assign de-
	      fault values as described	below.

	      root   A root device specification is of the form:

			    root on xy0d

		     If	a specific partition is	omitted	 --  for  example,  if

			    root on xy0

		     is	 specified  --	the  `a' partition is assumed.	When a
		     generic system is	being  built,  no  root	 specification
		     should  be	given; the root	device will be defined at boot
		     time by prompting the console.

	      swap   To	specify	a primary swap partition, use a	clause of  the

			    swap on partition

		     Swapping  areas  may be almost any	size.  Partitions used
		     for swapping are sized at boot time  by  the  system;  to
		     override dynamic sizing of	a swap area the	number of sec-
		     tors in the swap area can	be  specified  in  the	config
		     file.  For	example,

			    swap on xy0b size 99999

		     would  configure a	swap partition with 99999 sectors.  If
		     swap generic or no	partition is specified with on,	parti-
		     tion b on the root	device is used.	 For dataless clients,

			    swap on type nfs

	      dumps  The location to which system dumps	are sent may be	speci-
		     fied with a clause	of the form:

			    dumps on xy1

		     If	 no dump device	is specified, the first	swap partition
		     specified is used.	 If a device is	 specified  without  a
		     particular	partition, the `b' partition is	assumed.  If a
		     generic configuration is to  be  built,  no  dump	device
		     should  be	specified; the dump device will	be assigned to
		     the swap device  dynamically  configured  at  boot	 time.
		     Dumps  are	 placed	at the end of the partition specified.
		     Their size	and location  is  recorded  in	global	kernel
		     variables	dumpsize  and dumplo, respectively, for	use by

       Device names specified in configuration clauses are mapped to block de-
       vice  major numbers with	the file devices.machine, where	machine	is the
       machine type previously specified in the	configuration file.  If	a  de-
       vice  name  to  block device major number mapping must be overridden, a
       device specification may	be given in the	form:

		     major x minor y

       The second group	of lines in the	configuration file describe which  de-
       vices  your  system has and what	they are connected to (for example, an
       IPI Channel Adaptor on the VMEbus).  These  lines  have	the  following
		   dev_type	  dev_name    at    con_dev    more_info

       dev_type	 is  either  controller, disk, tape, device, device-driver, or
       pseudo-device.  These types have	the following meanings:

	      controller     A disk or tape controller.

	      disk or tape   Devices connected to a controller.

	      device	     Something "attached" to the main system bus, like
			     a cartridge tape interface.

	      device-driver  This  declares  support  for  a  device  of  name
			     dev_name.	For most devices on desktop  SPARCsys-
			     tems, this	is all that is required.  See `Desktop
			     SPARCsystem Input Grammar'	below for details.

	      pseudo-device  A software	subsystem or driver treated like a de-
			     vice driver, but without any associated hardware.
			     Current examples are the  pseudo-tty  driver  and
			     various  network subsystems.  For pseudo-devices,
			     more_info may be specified	as  an	integer,  that
			     gives  the	 value	of  the	 symbol	defined	in the
			     header file created for that device, and is  gen-
			     erally  used  to indicate the number of instances
			     of	the pseudo-device to create.

       dev_name	is the standard	device name and	unit number (if	the device  is
       not  a  pseudo-device)  of the device you are specifying.  For example,
       idc0 is the dev_name for	the first IPI disk controller in a system; st0
       names the first SCSI tape controller.

       con_dev	is  what the device you	are specifying is connected to.	 It is
       either nexus?, a	bus type, or a	controller.   There  are  several  bus
       types which  are	used by	config and the kernel.

       The possible bus	types are:
	      obmem		On board memory
	      obio		On board io
	      vme16d16 (vme16)	16 bit VMEbus/ 16 bit data
	      vme24d16 (vme24)	24 bit VMEbus/ 16 bit data
	      vme32d16		32 bit VMEbus/ 16 bit data
	      vme16d32		16 bit VMEbus/ 32 bit data
	      vme24d32		24 bit VMEbus/ 32 bit data
	      vme32d32 (vme32)	32 bit VMEbus/ 32 bit data
	      ipi		IPI pseudo bus (sun4 system only)

       All  of these bus types are declared to be connected to nexus.  The de-
       vices are hung off these	buses.	If the bus is wildcarded, then the au-
       toconfiguation  code  will  determine if	it is appropriate to probe for
       the device on the machine that it is running on.	 If the	 bus  is  num-
       bered, then the autoconfiguation	code will only look for	that device on
       machine type N.	In general, the	VMEbus	bus  types  are	 always	 wild-

       more_info is a sequence of the following:

	      csr address	Specify	 the  address  of the csr (command and
				status registers) for a	device.	 The  csr  ad-
				dresses	 specified for the device are  the ad-
				dresses	within the bus type specified.

				The csr	address	must be	specified for all con-
				trollers,  and	for all	devices	connected to a
				main system bus.

	      drive number	For a disk or tape, specify which  drive  this

	      flags number	These  flags  are made available to the	device
				driver,	and are	usually	read  at  system  ini-
				tialization time.

	      priority level	For  devices  which interrupt, specify the in-
				terrupt	level at which the device operates.

	      vector intr number [ intr	number . . . ]
				For devices which use vectored	interrupts  on
				VMEbus	systems, intr specify the vectored in-
				terrupt	routine	and number  the	 corresponding
				vector to be used (0x40-0xFF).

       A  ?  may be substituted	for a number in	two places and the system will
       figure out what to fill in for the ?  when it boots.  You can put ques-
       tion  marks  on	a con_dev (for example,	at virtual `?'), or on a drive
       number (for example, drive `?').	 This allows redundancy, as  a	single
       system  can  be	built which will boot on different hardware configura-

       The easiest way to understand config files it to	look at	a working  one
       and modify it to	suit your system.  Good	examples are provided in

   Desktop SPARCsystem Input Grammar
       Desktop	SPARCsystems'  usage  is  a good deal simpler than what	is de-
       scribed above, due primarily to information provided by the PROM	 moni-
       tor  that  obviates the specific	descriptions of	csr and	vector values.
       There is	no need	to declare a nexus, or a controller: all primary  con-
       trollers	 and  main I/O units are simply	described by the device-driver
       keyword.	 That is, a complete specification  of	all  UART  controllers
       (see zs(4S)) for	a desktop SPARCsystem is done by declaring:

		     device-driver  zs

       An  additional  keyword has been	introduced for desktop SPARCsystems to
       describe	SCSI disks and tapes that may be resident on the system: scsi-
       bus.  Its usage is:

		     scsibusN at device-driver

       which  declares	that  there  exists  a SCSI bus	supported by a device-
       driver previously declared.

       After specifying	that there is a	SCSI bus, you then can	specify	 disks
       and tapes that may be connected to this SCSI bus. For example, the dec-

		     disk sd0 at scsibus0 target 3 lun 0

       states that there may be	a disk (in this	example, sd0) attached to  sc-
       sibus0, at SCSI Target ID 3, SCSI Logical unit 0.

   SPARCsystem 600MP Series Input Grammar
       SPARCsystem 600MP series	machines have a	combination of both the	common
       input grammar (described	above in `Input	 Grammar'),  and  the  desktop
       SPARCsystem  grammar  (described	 above	in  `Desktop SPARCsystem Input
       Grammar').  For VMEbus devices, such as IPI, the	grammar	is similar  to
       the  common  grammar.   For  sbus devices, such as SCSI,	the grammar is
       similar to that of desktop SPARCsystems.

       Files in	/usr/share/sys/sun{3,3x,4,4c,4m}/conf which may	be useful  for
       developing the config_file used by config are:

	      GENERIC		  The  generic	configuration file for a given
				  Sun system.  This file contains all possible
				  device  description lines for	the particular

	      GENERIC_SMALL	  A reduced  generic  configuration  file  for
				  certain  vanilla  configurations.  Check the
				  comments at the top of the file for specific
				  architectures	and devices supported.

	      DLmodel, SDSTmodel, etc.
				  Many	of  the	 architectures supply template
				  configuration	files trimmed to support  only
				  certain  devices or environments (like disk-
				  less clients,	standalone systems  with  SCSI
				  disks	and tape, and so on).  Comments	at the
				  top of these files specify  models  and  de-
				  vices	supported.

	      README		  File describing how to make a	new kernel.

       As  shipped from	Sun, the files used by /usr/etc/config as input	are in
       the /usr/include/sys/conf directory:

	      config_file	  System-specific configuration	file
	      Makefile.src	  Generic prototype makefile for Sun-[34] sys-
	      files		  List of common files required	to build a ba-
				  sic kernel
	      devices		  Name	to  major  device  mapping  file   for
				  Sun-[34] systems

       /usr/etc/config	places	its  output files in the ../config_file	direc-

	      mbglue.s		  Short	assembly language  routines  used  for
				  vectored interrupts
	      ioconf.c		  Describes I/O	devices	attached to the	system
	      makefile		  Used with make(1) to build the system
	      device_name.h	  a   set   of	 header	  files	 (various  de-
				  vice_name's) containing devices which	can be
				  compiled into	the system

       gprof(1), make(1), zs(4S), kgmon(8), savecore(8), swapon(8)

       The SYNOPSIS portion of each device entry in Section 4 of this manual.

				 10 April 1991			     CONFIG(8)


Want to link to this manual page? Use this URL:

home | help