CONF(10.6) CONF(10.6)
NAME
conf - native and hosted kernel configuration file
DESCRIPTION
Native and hosted Inferno kernels are built for a given
target platform in the host environment in directory
/os/platform or /emu/platform. Existing platforms include
pc and ipaq for native kernels and Plan9, Linux, Nt (for all
versions of Windows), and Solaris, amongst others. Each
platform can have different kernels with different configu-
rations. A given configuration is built in the platform's
directory using the mk(10.1) command:
mk 'CONF=conf'
where conf is a text file that specifies drivers, protocols
and other parameters for that particular kernel: a parts
list. The result of a successful mk is an executable or
bootable file with a name determined by the platform's
mkfile, typically iconf for all native platforms, $O.conf
for Plan 9, Unix and clones, and iconf.exe for Windows.
A kernel configuration file has several sections of the form
label
item [ subitem ... ]
...
Each section begins with a label at the start of a line,
which names a configuration category, followed by a list of
each item to select from that category, one line per item,
with white space (ie, blank or tab) at the start of the
line. An item line can optionally list one or more subitems
that must be included in the kernel to support it. A line
that starts with a `#' is a comment. Empty lines are
ignored.
Labels are chosen from the following set, listed in the
order in which they conventionally appear in a configuration
file:
dev Device drivers
ip IP protocols (native kernels only) taken from ../ip
link Hardware-specific parts of device drivers.
misc Architecture-specific files; specific VGA and SCSI
interfaces
lib Libraries to link with the kernel
mod Builtin Dis modules
port Portable components (other than drivers) from
../port
Page 1 Plan 9 (printed 12/22/24)
CONF(10.6) CONF(10.6)
code C code and declarations to include as-is in the
generated configuration file
init Dis init program
root List of files and directories to put in the root(3)
file system
When an item is listed under a given label it causes a cor-
responding component to be included in the kernel. The
details depend on the label, as discussed below. Each
subitem represents a kernel subcomponent required by the
corresponding item. Both items and subitems can be either
portable (platform-independent) or platform-specific. The
source file for a given item or subitem is sought in the
platform-directory (for platform-specific code), and in
directories ../port and ../ip, under control of the
platform's mkfile and ../port/portmkfile (which is included
by mkfile). Resulting object files are left in the platform
directory.
Outside the dev section, each item and subitem x causes the
kernel image to include the code compiled from x.c, (or x.s
or x.S for assembly-language support), or portdir/x.c, where
portdir is one of the portable directories mentioned above.
In the dev section, an item x corresponds instead to the
driver source file devx.c in the current (platform-specific)
directory or a portable driver portdir/devx.c. Subitems are
handled as in any other section. Typically they are auxil-
iary files that are needed by the associated driver.
For instance, in a native kernel the portable driver for the
draw device uses platform-specific code from screen.c. That
can be represented as follows:
dev
draw screen
Each item x in the ip section corresponds to a protocol
implementation compiled from ../ip/x.c. Any subitems are
dealt with in the same way as in the dev section.
The link section provides a way for hardware-specific parts
of drivers to link at runtime to the hardware-invariant part
of a device drivers. For each item x, the kernel will call
the function xlink during its initialisation. Typically
that function makes itself known to the device driver by
calling a function provided by that driver, passing the
address of a interface-specific data structure or linkage
table. For example, ethersmc is an interface-specific com-
ponent:
link
...
Page 2 Plan 9 (printed 12/22/24)
CONF(10.6) CONF(10.6)
ethersmc
and its source file ethersmc.c provides a function
ethersmclink that calls addethercard in the interface-
invariant part of the driver, devether.c:
void
ethersmclink(void)
{
addethercard("smc91cXX", reset);
}
Similarly, during kernel initialisation, for each item x in
the mod section, the kernel calls the function xinit, to
initialise the corresponding built-in Limbo module.
The init section selects the first Dis program run by the
system. For native kernels, a given item x refers to
../init/x.dis, which is automatically built from
../init/x.b. For hosted kernels, emuinit is normally used,
referring to /dis/emuinit.dis.
The lib section lists the libraries to include when linking
the kernel, in an order that satisfies any dependencies
amongst them. Each item x corresponds to
/$SYSTARG/$OBJTYPE/libx.a, a target-specific library pro-
duced by compiling the C source code in /libitem, where
SYSTARG and OBJTYPE are set in mkfile to the target system
and object types.
An item in the root section has one of the forms:
name
name source
where name and source are both absolute path names rooted at
the Inferno source tree. The kernel's initial root file
system (see root(3)) will contain a file or directory with
the given name. Name must exist in the Inferno root, or an
existing source file must be named. In either case, if the
existing name refers to a file, the file in the root file
system will have that file's current contents. If it is a
directory, the root file file system will have a directory
with that name, but the directory will contain only those
names listed in the configuration file as belonging to that
directory. Source is often `/' to force a target name to be
a directory.
FILES
/emu/port/mkdevc
/emu/port/mkdevlist
/emu/port/mkroot
Page 3 Plan 9 (printed 12/22/24)
CONF(10.6) CONF(10.6)
/os/port/mkdevc
/os/port/mkdevlist
/os/port/mkroot
SEE ALSO
mk(10.1)
Page 4 Plan 9 (printed 12/22/24)