*BSD News Article 15144


Return to BSD News archive

Xref: sserve comp.os.386bsd.announce:41 comp.os.386bsd.questions:1995
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!agate!agate!usenet
From: burgess@hrd769.brooks.af.mil (Dave Burgess)
Newsgroups: comp.os.386bsd.announce,comp.os.386bsd.questions
Subject: FAQ_03
Followup-To: comp.os.386bsd.questions
Date: 25 Apr 1993 16:12:22 -0700
Organization: University of California, Berkeley
Lines: 332
Sender: cgd@agate.berkeley.edu
Approved: 386bsd-announce-request@agate.berkeley.edu
Message-ID: <9304212128.AA25515@hrd769.brooks.af.mil>
NNTP-Posting-Host: agate.berkeley.edu
Content-Type: text
X-Mailer: ELM [version 2.4 PL20]
Content-Length: 12567     




Section 3.	(Kernel Building and Maintenance)
3.1	Kernel

  One of the interesting aspects of 386bsd is the fact that it comes with
  the complete source.  This allows you to make changes to the system,
  recompile, and test out your new ideas.  This section of the FAQ
  describes many of the different aspects of this endeavour and common
  problems and pitfalls that are encountered.  Kevin Lahey provided the
  substantial portion of this section.  You can contact him via E-Mail 
  at (kml@rokkaku.atl.ga.us) or contact Dave Burgess 
  (burgess@hrd769.brooks.af.mil).


3.1.1	How do I build a kernel?

  The kernel can be compiled in a variety of ways to support
  different devices and configurations.  Compilation is controlled by a
  config file that specifies the characteristics of the kernel.
  A set of different config files is located in /sys/i386/conf.
  The configuration file names are in upper case.

  To build a particular kernel (in this example, we use the GENERICISA
  configuration file):

	% cd /sys/i386/conf
	% config GENERICISA
	% cd /sys/compile/GENERICISA
	% make depend
	% make

  You'll need patch 1 from the patchkit to get the compilation to work,
  'cause the version file isn't correctly included in the makefile.


3.1.2	I want to do one of the following things:
	* add a device not in the distributed kernel (third com
	  port, additional disk or tape, line printer driver, etc).
	* use a patch from the net or the patchkit to fix a kernel bug.
	* add another swap device.
	* recompile the kernel to remove extranious devices so that
	  it takes up less space.
	* configure more pseudo-terminals to allow for more xterms
	  or network logins.
	
  You're going to have to recompile the kernel after you modify the config 
  file.
  

3.1.3	I don't have the source distribution -- how can I rebuild the
	kernel?

  You can get the source for just the kernel from agate.berkeley.edu in the 
  directory /pub/386BSD/386bsd-0.1/filesystem/usr/src/sys.386bsd.  In 
  addition, you will need to get a few include files, and make sure that 
  all of the files that are actually symbolic links point to the right
  places.  It is around five megs of source and maybe another meg compiled.  
  There are also reference sites available, as well as the 'good net-neighbor'
  policy, whereby you could make arrangements with a net neighbor to use
  a large local machine as a Network File System, or allow you to compile
  a kew kernel on their machine and transfer it to yours.  If you *still* 
  can't fit it in, you'll have to ftp a compiled kernel from agate in the
  unofficial/patchkit-old directory or one of the archive sites.  You can
  also ask for help from comp.os.386bsd.questions if you get stuck and 
  cannot make any headway.


3.1.4	Now that I have a kernel, how do I install it?

  Your kernel is called /386bsd.  Copy the new kernel from 
  /sys/compile/GENERICISA/386bsd to /, assuming that it is in that directory.
  This is relatively straightforward; there are a couple of things to 
  remember, though.  First, if you really screw up the new kernel, you want 
  to have something to fall back on, so be sure to save /386bsd to 
  /386bsd.old before copying in a new kernel.  Second, if you just copy the 
  new kernel over the currently running kernel, funny things can happen.  Be 
  sure to move aside the currently running kernel before copying over the new 
  one.  

  There are folks that have reported that overwriting their current kernel
  has never caused them any real problems.  On the other hand, if the old
  kernel was working and the new one doesn't, and you have made changes that
  require that old kernel, it should be available to the system, and saving
  it to /386bsd.alt or /386bsd.old are reasonable things to do.

  If you are really paranoid, you can mount a new fixit floppy and replace 
  its kernel with the one you just built, and then boot from the fixit floppy 
  to make sure everything will work.  This is a pretty good idea if you are 
  making radical changes or if you are unsure about your changes.


3.2	What exactly is this config file, anyway?  What are all of
	these cryptic notations?

  I've annotated the distributed GENERICISA file;  my comments are deliniated 
  by the '--' symbols.

  #
  # GENERICISA -- Generic ISA machine -- distribution floppy
  #
  --
  BSD can be compiled for different hardware platforms, so it is important to
  define the hardware types.  386bsd can only be built for 386 or
  compatible machines, so this is sort of superflous, but maintains
  compatibility with standard BSD config files.
  --
  machine		"i386"
  cpu		"i386"
  --
  The ident describes the machine for which this kernel is to be built.
  It is usually the system name -- "ROKKAKU", "REF", or whatever.
  This can be used for conditional compilation, so that kernel changes
  can be compiled in only for one machine.
  --
  ident		GENERICISA
  --
  This should indicate the timezone of the system relative the
  Greenwich.   8 is PST;  4 is EST.  Somebody else might want to discuss
  this more fully.
  --
  timezone	8 dst
  --
  maxusers isn't strictly checked;  it is just used to size several
  system data parameters.
  --
  maxusers	10
  --
  The options control the conditional compilation of features into the
  kernel.  The options can be listed all on a line separated by commas.
  They are #define'ed when the kernel is compiled, so that #ifdef's
  will work.  An option can be given a value by appending an equals sign
  and a value (enclosed in double quotes) to the option name.
  
  Hopefully the names are at least somewhat self-explantory.  To
  discover what everything does, you'd have to go through the kernel
  looking for all of the appropriate #ifdef's.
  
  [Perhaps somebody else could list the *exact* meanings of these
  options and some of the other possible options?]
  --
  options		INET,ISOFS,NFS
  options		"COMPAT_43"
  options		"TCP_COMPAT_42"
  
  --
  The config line controls the location of the root, swap, and dump
  devices.  Anything not specified is defaulted.  This is where you add
  support for multiple swap devices.  Just list 'em, separated by 'and'.
  The config line below identifies the root drive as wd0 and the
  swap drives as wd0 and as0.  See the section on swap devices in FAQ_02
  for additional information.
  --
  config		"386bsd"	root on wd0 swap on wd0 and as0
  --
  A 'controller' is a device or bus controller.  'isa' is obviously for
  the ISA bus.  'wd0' is for regular disk controllers,  'fd0' is for the
  floppies, and 'as0' is for SCSI disk controllers.
  --
  controller	isa0
  --
  The fields work as follows:
  
  a.  What do you call this device?  
  b.  What controller is this on?  As you can see, the disk controller
  talks to the ISA bus, and the disks talk to the disk controller.
  c.  Where are the registers for the controller mapped into memory?
  This is #defined in /sys/i386/isa/isa.h.
  d.  What IRQ is this device set up for?
  e.  What routine should be called on an interrupt from the device?
  
                 a          b           c             d           e
                vvv        vvv       vvvvvvv          vv        vvvvvv
  --
  controller	wd0	at isa? port "IO_WD1" bio irq 14 vector wdintr
  --
  You need a 'disk' entry for every disk on the controller.  In the
  config file originally shipped with 386bsd, both hard disks were 
  incorrectly idenitified as wd0.  Be sure to change the second occurence 
  to wd1, as I have done in below.
  --
  disk		wd0	at wd0 drive 0
  disk		wd1	at wd0 drive 1
  
  controller	fd0	at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
  disk		fd0	at fd0 drive 0
  disk		fd1	at fd0 drive 1

  --
  The 'drq' specifies the channel used for bus-mastering DMA??
  --
  controller	as0	at isa? port 0x330 bio irq 11 drq 5 vector asintr
  disk		as0	at as0 drive 0
  disk		as1	at as0 drive 1

  --
  Define other physical devices.  pc0 is the keyboard, npx0 drives the
  math coprocessor, and com* controls the com ports.
  --
  device		pc0	at isa? port "IO_KBD" tty irq 1 vector pcrint
  device		npx0	at isa? port "IO_NPX" irq 13 vector npxintr
  device		com1	at isa? port "IO_COM1" tty irq 4 vector comintr
  device		com2	at isa? port "IO_COM2" tty irq 3 vector comintr
  
  --
  Ethernet drivers of various sorts and the particular configuration
  information they require.
  --
  device we0 at isa? port 0x280 net irq 2 iomem 0xd0000 iosiz 8192 vector weintr
  device ne0 at isa? port 0x300 net irq 2 vector neintr
  device ec0 at isa? port 0x250 net irq 2 iomem 0xd8000 iosiz 8192 vector ecintr
  device is0 at isa? port 0x280 net irq 10 drq 7 vector isintr

  --
  Tape driver
  --
  device		wt0	at isa? port 0x300 bio irq 5 drq 1 vector wtintr
  
  --
  The TCP/IP loopback device, ethernet interface, slip interface, log
  device, and pseudoterminals.
  --
  pseudo-device	loop
  pseudo-device	ether
  pseudo-device	sl	2
  pseudo-device	log
  pseudo-device	pty	4
  
  --
  Devices required by VM.  Why are they here?
  --
  pseudo-device	swappager
  pseudo-device	vnodepager
  pseudo-device	devpager
  

3.2.1	Okay, fine.  Why shouldn't I just add every device I can find to
	the kernel, so I'll never have to recompile this again?

  Because it takes up space.  The kernel is wired into memory, so every 
  byte it uses comes out of the pool of memory for everything else.  It 
  can't page out sections that aren't in use.  If your kernel is larger 
  than 640K, then it can't be loaded.  You'll need to use Julian Elischer's
  bootblocks to put it in high memory, which seem to be fairly complex.
  Installing them (once they are compiled) is as easy as using disklabel.


3.2.2	What should I remove from the kernel?

  What do you need?  If you have a SCSI controller, you don't need the wd0 
  device;  if you have another kind of disk controller, you don't need as0.  
  Unless you actually HAVE more than one Ethernet controller, you should
  comment out all but one of them.  If you don't have an ethernet controller, 
  you don't need any of the controllers or NFS compiled in.  Without a 
  CD-ROM, ISOFS is kind of pointless.  Just look at what you have and think 
  about what you really need.


3.2.3	I can't get enough remote login sessions or xterm sessions.  What
	can I do?

  Increase the count of pseudoterminals --

	pseudo-device	pty	12  # or whatever

  Every psuedo terminal should have a /dev/pty* entry.  If you have 12
  psuedo terminals, you should also have at least 12 pty devices in the
  /dev directory.  The MAKEDEV script in /dev will create up to 32 (?)
  psuedo terminals automatically.


3.2.4	How do I get ddb, the kernel debugger, compiled into the kernel
	and running?

  Add the following line to the configuration file:

	pseudo-device	ddb

  Build the kernel, then run dbsym on it:

  % dbsym ./386bsd

  Install it and go for it.  Ctl-Alt-Esc drops you into the debugger.


3.2.5	Can I have more than one config file?  Should I rename it to something
	else?  Any other hints?  

  You can create as many (or as few) config files as you desire.  The system,
  once the patchkit is applied, will have between 10 and 15, each of which
  implements certain functions or features.  In addition, the normal place
  for the patchkit to make changes to the config files is in the
  GENERICISA file.  Since this file should remain unchanged and available,
  it is always a good idea to copy this file to a meaningful name and
  modify that file.  In other words, change every reference in 3.1.1 from
  GENERICISA to HAL (or whatever you call your system).

  One final note.  Every /sys/compile directory takes up 800K or so;
  you might want to watch to see how big these all get.


3.2.6	Where can I learn more about all this?

  We've skipped over alot of details here;  the straight dope comes from
  "Building Berkeley UNIX Kernels with Config", by Samuel J. Leffler and
  Michael J. Karels. 

3.3	X11/XFree86/XS3
3.3.1	What options should I define to get the X extensions included?

  Once you have applied the patch kit, the only thing left to do is to
  modify the config file to include the following line:

	options	XSERVER, UCONSOLE
 
  recompile the kernel and the kernel should support X.

3.3.2	Where can I get the FAQ for 'X'?

  The 'X' FAQ is posted to comp.os.386bsd.apps at regular intervals, as
  well as news.answers, comp.answers, and several other places.  It
  is also available for anonymous FTP at rtfm.mit.edu in the ???
  directory.


3.4	Compiler and Library routines

[ this was really an empty section! -- cgd ]
--
Please send submissions for comp.os.386bsd.announce to:
					386bsd-announce@agate.berkeley.edu