Constructing Source Code Dependencies; Building The Kernel - Sun Microsystems Sun Workstation 100U System Manager's Manual

Building Sun Workstation Kernels Kernel Building Process
particularly if yoUr hardware is configured at non-standard places (for example, device registers
located at funny places or devices not supported by the kernel). If the devices to be configured
are not already described in one of the existing configuration files, check the section 4 manual
pages in the Sun Sydem Interface Manual. For each supported device, the manual page
synopsis entry gives a sam pie configuration line.
Once the configuration file is complete, run it through config and look for any errors. Never use
a kernel which con/ig has complained about; the results are unpredictable. For the most part,
config's error diagnostics are self-explanatory. It may be the case that the line numbers given
with the error messages are off by one.
A successful run of config on your configuration file will generate a number of files in the
configuration directory. These files are:
• A file to be used by make(l) in compiling and loading the kernel.
• One file for each possible kernel image for your machine which describes w here the root and
swap devices are located.
• A collection of header files, one per possible device the kernel supports, which define the
hardware configured.
• A file containing the i/o configuration tables used by the kernel during its autoconfiguration
phase.
Unless you suspect that there is a bug in co nfig , or are curious about how the kernel's
autoconfiguration scheme works, you should never have to look at any of these files.
1.3. Constructing Source Code Dependencies
When config is done generating the files needed to compile and link your kernel it will terminate
with a message of the form "Don't forget to run make depend". This is a reminder that you
should change your working directory to the configuration directory for the kernel just
configured, and type "make depend" to build the rules used by make to recognize interdepen-
dencies in the kernel source code. This will insure that any changes to a piece of the kernel
source code will result in the proper modules being compiled the next time make is run.
This step is particularly important if your site makes changes to the kernel include files. The
rules generated specify which source code files are dependent on which include files. Without
these rules, make will not recognize when it must rebuild modules due to a kernel header file
being modified. Note that dependency rules created by this step only reflect directly included
files. That is, if file "a" includes another file "b", which includes yet another, say "c", and then
"c" is modified, make will not recognize that "a" should be recompiled. It is best to keep
include file dependencies only one level deep.
1.4. Building the Kernel
The makefile constructed by config should allow a new kernel to be rebuilt by simply typing
"make image-name". For example, if you have named your bootable kernel image "vmunix",
then "make vmunix" will generate a boot able image named "vmunix". Alternate kernel image
names are used when the root file system location and/or swapping configuration is done in
more than one way. The makefile which config creates has entry points for each kernel image
defined in the configuration file. Thus, if you have configured "vmunix" to be a kernel with the
root file system on an "xy" device and "ipvmunix" to be a kernel with the root file system on
an "ip" device, then "make vmunix ipvmunix" will generate binary images for both.
7 January 1984 3