The graph.comp file is divided into three sections: device drivers, protocols, and miscellaneous configuration parameters. The sections are separated by lines beginning with @; each section may be empty.
The first two sections---device drivers and protocols---describe the protocol graph to be configured into the x-kernel . The only difference between the two sections is that drivers in the first section are initialized directly from the x-kernel boot thread, whereas protocols in the protocol section are initialized from a distinct protocol initialization thread. For the device drivers and platforms in this distribution, this distinction is of no consequence and device drivers may be configured in either the first or the second section.
Device drivers and protocols are described by the same types of entries, as illustrated by the following example.
name=asp files=asp dir=asp protocols=ip,eth trace=TR_MAJOR_EVENTS;
The first field gives the protocol's name. The rest of the fields are optional and may occur in any order. The dir and files fields describe the names and locations of the source files that implement the protocol. Files are specified without extensions. The dir and files fields are not used in the common case where you want to link in protocol object code from the public system object area (/usr/xkernel/protocols); they are used only when you want to compile and link code from your private build area. If a files entry exists but no dir entry is specified, the current directory (i.e., the build directory) is assumed. If a dir entry exists without a files entry, the files field defaults to a single .c file with the protocol's name.
The protocols field indicates the protocols directly below the current protocol in the graph, that is, the protocols upon which this protocol depends. When this field contains multiple protocols, order is significant; the lower protocols will be loaded into the upper protocol's down vector in the order in which they are listed. A protocol tha expects multiple protocols below it will describe the expected semantics of the lower protocols in its manual page in Appendix A.
The trace field defines the debugging level used in trace statements depending on the protocol variable traceaspp.
Multiple instantiations of protocols are supported by using a ``/'' character after the protocol name, and then adding a unique suffix. In the following example, two instantiations of ``asp'' are indicated, one over ``ip'' and one over ``eth,'' and both are used by the ``prt'' protocol. In this example, each instance suffix for the ``asp'' protocol is the name of the protocol below the instance, but this is just a convention; any distinct string could be used as an instance suffix. Note that only the first of multiple instantiations should have dir, files, or trace fields.
name=asp/ip files=asp dir=asp protocols=ip trace=TR_MAJOR_EVENTS;
name=asp/eth protocols=eth;
name=prt files=prt dir=prt protocols=asp/ip,asp/eth trace=TR_ERRORS;
The third section of graph.comp contains the names of protocol table files that are to be loaded during initialization. It also contains the names of subsystems and their configuration parameters. Currently, trace variables are the only configuration parameters that can be set here. The following illustrates a typical use of the third section.
@;
#
# You can specify protocol tables to be read in at boot time.
#
prottbl=/usr/xkernel/etc/prottbl.std;
prottbl=./prottbl.local;
#
# You can specify subsystem tracing for messages and protocol operations
# (see file include/xk_debug.h for a list of subsystem trace variables).
#
name=msg trace=TR_GROSS_EVENTS;
name=protocol trace=TR_MAJOR_EVENTS;
#
# You can specify the name of the ROM file to be used; it will be read
# during "make compose" and incorporated into the xkernel runtime image.
#
romfile=romfile.asp;
#
# You can specify romfile contents (see section "ROM options").
#
romopt shepherd threads 8;
The graph.comp file is read by an x-kernel utility program called compose. This utility generates startup code to build the protocol graph and set up the described configuration. The protocol graph is built bottom-up; when a protocol's initialization function is called, the lower level-protocols have already been initialized.