Editing the Kernel

This is probably one of the best things you can do to your Sun3 to improve it's overall performance since memory and CPU cycles are often wasted dealing with drivers for items that are probably not part of your particular setup.

For those of you still fairly unfamiliar to UNIX, the "kernel" generates an executable file that is a primary component of the OS, essentially, the file that allows your computer to boot. If you're on a machine, cd to the root of the filesystem and type "ls -l", and you should see a file named "vmunix", and this is the file we are discussing.

-rwxr-xr-x  1 root       812619 Jul  3 19:55 vmunix
My kernel was generated on July 3rd 1998 and is about 800k. Before I made the changes to the kernel, this file was well over a megabyte (1,247525 bytes) and consumed almost 6 megs of ram by the time I first booted the machine. By comparison, my Sun3 now only uses about 4.7 megs of ram when it first boots. Furthermore, the trimmed kernel boots faster, since it does not waste time looking for devices that don't exist.

The first step is to determine what exactly is on your system. This can usually be determined with the dmesg command. Here's mine for example:


Sep 25 12:17
SunOS Release 4.1.1_U1 (MOD_160BC) #1: Fri Jul 3 19:54:17 EDT 1998
Copyright (c) 1983-1991, Sun Microsystems, Inc.
mem = 16384K (0x1000000)
avail mem = 15646720
Ethernet address = 8:0:20:1:cc:bc
si0 at vme24d16 0x200000 vec 0x40
st0 at si0 slave 32
sd0 at si0 slave 0
sd0:  -Micropolis 1558 cyl 1218 alt 2 hd 15 sec 35-
sd1 at si0 slave 1
sd1:  -Micropolis 1558 cyl 1218 alt 2 hd 15 sec 35-
zs0 at obio 0x20000 pri 3
zs1 at obio 0x0 pri 3
ie0 at obio 0xc0000 pri 3
bwtwo0 at obmem 0xff000000 pri 4
bwtwo0: resolution 1152 x 900
root on sd0a fstype 4.2
swap on sd0b fstype spec size 29925K
dump on sd0b fstype spec size 29896K

So you can see that I have 1 scsi controller driving one tape drive (st0) and two scsi harddrives (sd0 and sd1). Anything else in the kernel that might have accessed other SCSI devices is not needed, unless later I decide to add more to the machine - but then I'd just have to re-edit and rebuild the kernal again to access those extra devices. In the meantime, by only telling the machine about what I have, the machine is faster since it isn't "looking" for anything beyond what I know is in there.

The control files for the kernel are pretty well commented. I've included access to the generic kernel and my current kernel through these links.


The Process of Editing and Compiling the Kernel

Configuration files are in the /usr/kvm/sys/"arch"/conf directory, where "arch" is the kernel architecture of the machine. Obviously, if you're on a Sun3 system, you want to go into the sun3 directory.

It's recommended that you make a copy of whatever file you will be editing and work on the copy. You'll probably have to do everything as root, since the protection bits won't allow just anyone to edit critical files!

Sun 3 >ls
DL             GENERIC        SDST110        Sun3_160       devices
DL110          GENERIC_SMALL  SDST160        XDMT160        files
DL50           MOD_160BC      SDST260        XDMT260
DL60           Makefile.src   SDST50         XYMT160
DL75           README         SDST60         XYMT260
The files in all caps are the configuration files. These can be loaded and edited in the text editor of your choice. GENERIC contains information covering every configuration and device in that kernel architecture. If you've done a fresh install of your OS or are running a version of the OS that echos back "GENERIC" at boot up (or again, you can see this by using the dmesg command), then this is the file your system is using. But chances are, it's not the one you want to use because very few systems run with so many devices.

Instead, you want to pick a particular machine template file and edit that (copy it first, giving it a unique name). Each template has a code to it -- "DL" signifies that it's for a diskless client, "SD" indicates a SCSI disk based system. "XD" and "XY" systems are Xylogics controller based. Choose the file that most closely resembles your current system setup.

Once you've loaded the file into your text editor, I suggest that rather than delete un-needed parts, you merely comment them out with the # symbol starting the line. The template files are usually well-commented to reading them is self-explainatory. Commenting out un-needed parts makes mistakes easier to correct later (personal experience learned the hard way).

One item in the file that needs mentioning is the maxusers limit. The default is 8. If you use your machine as a telnet or terminal only style machine, you can probably lower this amount to save ram, unless your machine is server, in which case, you'll want to add users. However, if you are using a graphical windowing system like X-windows or Sunview, each shell window that you open counts as a seperate user - therefore, if you are running Sunview, you may want to raise this number. It's not a hard-limit by any means, but it determines the way structures are created for the kernel. Some people think that 8 is as low as you should go, but in my experience, it really depends upon how you use the machine.

Also, when you're commenting out a particular SCSI controller, make sure you comment out it's associated disk drives and tape drives. Determining your proper SCSI controller and then removing the ones you don't need saves memory and improves performance.

When you're done, run config on your now edited, uniquely named file. If all goes well, it will echo back "doing a "make depend"". What is happening during this time is that config is making a directory with the same name as your file, filling it with the files needed to make a kernel, and creating a Makefile file.

When that's done, cd up one directory and then into the directory with the name of your unique configuration file. once you're in that directory, just type "make", and the magic will happen. You'll see alot of output as the kernel is built. Once it's done, you'll see a new "vmunix" file in that directory. jump back to your root directory, rename your old vmunix to vmunix.bak or something similar, and then move the new vmunix file to the root. Reboot, and if all goes well, your machine will boot up with a more streamlined kernel.


What To Do If All Doesn't Go Well

Ha, thought I wasn't going to cover this, eh? Usually, 2 things can go wrong.

The machine boots, but some devices fail:

This is pretty easy to fix - go back into your unique configuration template, figure out what you commented out but shouldn't have, and rebuild your kernel yet again, and again replace the old kernel with the newly built one.

The machine doesn't boot at all:

This is a little tougher to solve, but thanks to the miracle of boot-rom on Sun systems, you can actually specify which vmunix file to boot from. Therefore from the bootmonitor prompt, figure out your boot string, specifiying SCSI adapater or drive, and include the vmunix.bak (or whatever you named it) as your kernel. The system will then reboot using the old kernel. Delete the newer kernel and rename the old one. After that, reboot again, and then go and start over, because you obviously left out something critical, like specifying the wrong SCSI controller. It may take you a couple of tries before you get everything perfect, but just think of how much better the machine will run once you do get it right.


One final warning:
Whatever you do, DO NOT delete anything until you are POSITIVE that everything is working perfectly. Remember that the advantage of the GENERIC kernel is that it'll run on practically anything in it's architecture class, and if you have a hodge-podge system built out of alot of different items, you may need to grab stuff out of other template files before everything works as it should.

Good Luck!