Building a Kernel

Warning: Understand what you are doing before attempting this on your system. If is very easy to build a kernel that will not boot! Make sure you keep a copy of your original kernel and you understand how to boot an alternate kernel.

What is a Kernel

We discussed this in previous sections such as system startup. However, it is important to understand the role of the kernel. Through the use of system procedure calls the kernel provides controlled access to the underlying hardware on behalf of the user. The kernel is responsible for 1) scheduling the CPU, 2) accessing devices on behalf of the user, 3) controlling resource allocation. 4) and creation and deletion of processes. Since all of these functions are fundamental to the use of the system we see how critical the kernel is.

System routines such as read or write are executed within a user process; however these calls are ultimately dispatched to the kernel to perform the actual read or write of the data. The kernel then returns the data back to the user's process address space. As a user, you may not realize that the kernel is acting on your behalf.

Why do we have to build a kernel

Concievably Unix can (and in some cases does) ship with a generic kernel that can be run across an entire line of systems. However, most vendors offer a tremendously wide range of hardware and software options in which to run Unix. A generic kernel must include all possible combinations of devices and cannot optimally be sized. A generic kernel usually requires much more memory than a customized kernel.

In addition, in order to add new devices we must generally build a kernel that understands the devices we have on the system. A program named a device driver functions as the intermediary between the kernel and the actual device. Under most versions of Unix device drivers must be pre-defined within the kernel. Some systems, such as Solaris, now provide dynamic loading and unloading of device drivers which can eliminate this need.

Over the years as systems have evolved the need to build kernels has been reduced. Now many system administrators will use a generic kernel, even though that kernel may require more RAM than one customized. Losing one megabyte of memory of modern day workstation is not that critical. Previously, Unix might be running in a system with 4 MB or 8MB of RAM, freeing up a single megabyte could be critical.

The NeXT computer system is based on the CMU Mach Operating system and has no kernel configuration files that must be built. The Mach kernel is a very small kernel that provides features to additional kernel modules such as device drivers. Mach was designed to allow dynamic loading of these services on top of the small kernel. As such, the NeXT dynamically configures itself. This model, call micro-kernel, will be the basis for most future variants of Unix as well as other operating systems (e.g. Windows NT).

Legitimate reasons for building a new kernel

For example, when you add an application such as a database package you often have to radically increase semaphore resources or shared memory data sizes. Thus, you must reconfigure the kernel to handle that application.

Building a Kernel under System V (SGI)

Under the SGI IRIX version of Unix, all kernel configuration files reside under the directory tree /usr/sysgen. There are four sub-directories there named: 

system   --   A file defining the modules to use, compiler options, vector and
              device driver information.

master.d --   A directory containing the system configuration files. One file
              for each major component and device.

boot     --   A directory containing the object files to be linked togethor
              to form the new kernel. 

root     --   A directory tree for a minimal system file tree containing
              software needed to build a new kernel.

Steps in building a kernel

  1. Log in as root and move to the directory /usr/sysgen.
  2. Make sure you have edited the system file and uncommented the areas that match your hardware. A copy of the system config file for one of our SGI machines is here.
  3. Then move to the sub-directory master.d, edit the appropriate files to change any parameters you need. A copy of the file for the kernel is here. Make sure you document what value you changed and what the original value was. Kernel files are often a good choice for a source-code control system.
  4. move back to the /usr/sysgen directory and issue the command lboot -u /unix.install. The lboot command will build a new kernel named /unix.install for you.
  5. Create a backup copy of your current running kernel using the ln command. Use ln /unix /unix.orig .
  6. reboot the machine. Under IRIX, the system will ask if you wish to install a new kernel and overwrite the standard kernel /unix with the contents of the /unix.install file.
  7. Test your kernel and verify everything works.

      A key parameter to set correctly on a SYStem V based kernel is the NPROC parameter in the kernel configuration file. This value controls the maximum number of processes on the system and is used to size the system data structures. In the section on adding devices we will discuss the additional steps needed to handle adding new devices to the running kernel.

      Building a Kernel under BSD based systems (Ultrix)

      Under most BSD versions of Unix the system configuration files reside under the /sys/ directory. Under Ultrix, which ran on different hardware architectures there was a dsub-directory named either VAX or MIPS depending on the hardware type. The standard on berkeley systems is to create the name of the kernel configuration file is uppercase letters and have it match the hostname of the system. A copy of the configuration file for UMBC4 is here.

      Steps in building a new kernel

      1. Create a backup copy of the configuration file for the kernel.
      2. Change the file to change the correct parameters.
      3. Run the command config FILE. This will create a directory under the name FILE
      4. change your directory to the correct subdirectory and issue the command make clean.
      5. Issue the command make depend to build togethor the system dependencies.
      6. Issue the command make to build a new kernel.
      7. Save your original kernel as /vmunix.orig
      8. Move the kernel you just built to the root directory as /vmunix.
      9. reboot the system and test your kernel.

      Under Ultrix, a key value to set is the MAXUSERS parameter. This parameter is used to then size many kernel data structures. It does not limit the number of logins but does determine how many concurrent users your system can expect to support.