2. Creating a Custom Kernel


Contents of this section

2.1 Acquiring sources

There are two basic methods of acquiring kernel sources. The first method is to download a gzipped tar file from a standard release. This is the method for those who are doing anything but "bleeding edge" kernel development. The second method is to "sup" or otherwise get the current files from sup.netbsd.org or ftp.netbsd.org on a regular basis.

For the first method, download the ksrc file from a NetBSD/mac68k distribution site and extract it according to the directions for that release (usually in the INSTALL document).

A quick road map to the source is the subject of the next section .

The second method requires more dedication and adventure. The current sources are not guaranteed to run, or even compile, at any given time. There are several way to accomplish this task. With a direct internet connection, it is possible to use the CMU sup(1) utility to retrieve the changes daily. This is certainly the least work. See the supkit for instructions on how to set this up. The supkit can be obtained from NetBSD/mac68k distribution sites.

Without a direct internet connection, it is necessary to get the files by hand. The safest way is to get the entire sys tree at once:

ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/src/sys.tar.gz
The extension .tar.gz means that the file is created with the tar command and then gzipped to save space. Usually, kernel source is kept in /usr/src/sys, but it is a good idea to do active development in another location. To extract the above file, go to the directory where the sources should be extracted and type:
tar xvzf sys.tar.gz
This will list the files as it extracts them.

Individual files can be obtained from the source tree:

ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/ ...

2.2 A Quick Map

This is a very general overview of what is in most of the kernel source directories.

 src/
  sys/          - Kernel source top level
   arch/        - Architecture specific directories
    alpha/      - DEC Alpha-based systems
    amiga/      - Commodore Amiga systems (m68k)
    arm32/      - Acorn RiscPC machines
    atari/      - Atari TT/Falcon systems (m68k)
    hp300/      - HP 300-series systems (m68k)
    i386/       - Intel 80x86 systems
    m68k/       - Generic code shared between the m68k platforms
     include/   - This becomes /usr/include/m68k
    mac68k/     - 68K Macintosh-specific code
     dev/       - Device drivers
     include/   - This becomes /usr/include/machine
     mac68k/    - General machine dependent files.  Like locore/trap/etc
     conf/      - Configuration directory
     scsi/      - The SCSI subsystem.  This should eventually be sys/scsi
     compile/   - Configured kernels are built here
      GENERIC/  - A generic kernel
    mvme68k/    - Motorola 68k-based VME boards (m68k)
    pc532/      - NS32532-based net-brew systems
    pica/       - Acer Pica systems
    pmax/       - DEC MIPS-based DECStations
    powerpc/    - PowerPC-based Open Firmware systems
    sparc/      - Sun sparc-based systems
    sun3/       - Sun3-series systems (m68k)
    vax/        - DEC VAX systems
    x68k/       - Sharp X680x0 systems
   compat/      - Compatibility code for SunOS, Linux, SVR4 and others
   conf/        - Machine-independent configuration directory
   ddb/         - Machine-independent code for the kernel debugger
   dev/         - Device drivers that aren't tied to specific architectures
   kern/        - Core kernel functions
   lib/         - Kernel, compat, and standalone libraries
   lkm/         - Loadable Kernel Module code
   *fs/         - Code for various filesystems
   net*/        - Networking stuff
   nfs/         - Network File System
   scsi/        - Machine-independent scsi system
   sys/         - Becomes /usr/include/sys
   vm/          - Machine-independent virtual memory code

2.3 Defining a configuration

Traditionally, BSD systems have had a program called "config" to take a configuration file as input and generate a Makefile with which you build a kernel. 4.4 BSD has generalized the machine-specific nature of this older system.

Like the older config, this new config uses a configuration file. SYSTEM shall be used in this description, but GENERIC, BASIC, and EARWIG are equally acceptable names. GENERIC has some special meaning, though, as we shall see later. Various options and drivers are specified, and std.mac68k is included from this file for the basic devices. See the Options section for a brief summary of some of the more common options. Getting a working system configuration file from scratch can be a frustrating experience, so it's recommended that new configurations be derived from existing files.

Config for NetBSD/mac68k uses the following files for information:

        sys/arch/mac68k/conf/SYSTEM
        sys/arch/mac68k/conf/std.mac68k
        sys/arch/mac68k/conf/files.mac68k
        sys/arch/mac68k/conf/Makefile.mac68k
        sys/arch/m68k/conf/files.m68k
        sys/conf/files
With these it creates a directory called sys/arch/mac68k/compile/SYSTEM and all the necessary files for building a kernel.

For example, assume joe_blow@earwig has the sources extracted in his home directory:

joe@earwig:~/sys/arch/mac68k/conf % config SYSTEM
Don't forget to run "make depend"
joe@earwig:~/sys/arch/mac68k/conf % 

Please note that you need to be using a version of config which matches your sources. The format of the configuration file tends to change slightly between releases, so it is a good idea to compile your own copy of config before you begin to configure your own kernel.

2.4 Compiling

Simply change directory to the directory that config created or updated in step 2 and type "make depend ; make".

Continuing the example from above:

joe@earwig:~/sys/arch/mac68k/conf % cd ../compile/SYSTEM
joe@earwig:~/sys/arch/mac68k/compile/SYSTEM % make depend ; make
This step for the GENERIC configuration takes about 1.5 hours on an SE/30 with 8MB that is otherwise idle. Speeding it up is work-in-progress.

2.5 Installing

Simply copy the kernel into the root directory and reboot. In case there is a problem with the new kernel, do not copy it to /netbsd. Use /netbsd.test or something like that. Then, in the "Booting..." dialog of the booter, specify the test kernel's name. After the kernel boots successfully, move /netbsd to /netbsd.old or /netbsd.bak and move the new netbsd.test to /netbsd. In general, the following naming conventions are useful:

        /netbsd         -- Current kernel.  This is necessary for
                           programs like ps and w that need to read
                           information from /netbsd.
        /netbsd.test    -- Test kernel.  Temporary.
        /netbsd.dist    -- Last distributed kernel.  Hopefully known
                           to work.
        /netbsd.last    -- Last custom kernel that has been used for
                           some time and is known to work.
        /onetbsd        -- An old kernel as a backup in case everything
                           else fails.


Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter