Sharing Object Modules; Building Profiled Kernels - Sun Microsystems Sun Workstation 100U System Manager's Manual

Kernel Building Process
Building Sun \Vorkstation Kernels
Note that the name of a bootable image is different from the system
id~ntifier.
All bootable
images are configured for the same devices; only the information about the root file system and
paging devices differ.
The last step in the kernel building process is to rearrange certain commonly used symbols in
the symbol table of the kernel image; the makefile generated by config does this automatically
for you. This is advantageous for programs such as
p.,(l)
and vm&tat(8), which run much faster
when the symbols they need are located at the front of the symbol table. Remember also that
programs such as p., and vmdat expect the currently executing kernel to be named "/vmunix".
If you install a new kernel and name it something other than "/vmunix", these programs are
likely to produce incorrect results.
1.S. Sharing Object Modules
This is only effective it you have a source distribution.
If you have many kernels which are all built on a single machine there are at least two
approaches to saving time in building kernel images. The best way is to have a single kernel
image which is run on all machines. This is attractive since it minimizes disk space used and
time required to rebuild kernels after making changes. However, it is often the case that one or
more systems will require a separately configured kernel image. This may be due to limited
memory (building a kernel with many unused device drivers wastes core), or to configuration
requirements (one machine may be a development machine where disk quotas are not needed,
while another is a production machine where they are), etc. In these cases it is possible for ker-
nels to share relocatable object modules which are not configuration depende!lt; most of the
modules in the directory / 8Y"/ 8Y" are of this sort.
To share object modules, first build a GENERIC kernel. Then, for each kernel, configure as
before, but before recompiling and linking, type "make links". This will cause the kernel source
to be searched for source modules which are safe to share between kernels and generate sym-
bolic links in the current directory to the appropriate object modules in the directory .. /
GEN-
ERIC. A shell script, "makelinks" is generated with this request and may be checked for
correctness. The file
ByB /
conl/ define., contains a list of symbols which we believe are safe to
ignore when checking the source code for modules which may be shared. Note that this list
includes the definitions used to conditionally compile in the virtual memory tracing facilities,
and the trace point support used only rarely. It may be necessary to modify this list to reHect
local needs. Also, as described previously, interdependencies which are not directly visible in the
source code are not caught. Thus if you place per-system dependencies in an include file, they
will not be recognized.
1.6. Building Profiled Kernels
This is only effective if you have a source distribution.
It is simple to configure a kernel which will automatically collect profiling information as it
operates. The profiling data may be collected with kgmon(8) and processed with gpro/(l) to
obtain information regarding the kernel's operation. Profiled kernels maintain histograms of the
program counter as well as the number of invocations of each routine. The gpro/(I) command
will generate a dynamic call graph of the executing kernel and propagate time spent in each
routine along the arcs of the call graph.
4
7 January 1984