Other Things to Try

Now that you are able to build a vanilla system, you can start experimenting with different optional configurations. The following gives a list of things you might try. Consult the Programmer's Manual for more information on each item.

• Edit graph.comp in your build directory by adding the string

  trace=TR_MAJOR_EVENTS

  to the end of each of the following four lines

  name=eth protocols=simeth;
  name=arp protocols=eth;
  name=ip protocols=vnet;
  name=tcp protocols=ip;

  For example, the first line would become

  name=eth protocols=simeth trace=TR_MAJOR_EVENTS;

  Similarly with the other lines. Once this edit is done, repeat steps 9 and 10 from above. This change will increase the amount of tracing information that is output when the x-kernel runs. This output will now include events from TCP, IP, ARP, and the Ethernet driver (ETH). To see an even greater level of trace detail, change TR_MAJOR_EVENTS to TR_FUNCTIONAL_TRACE in each of the above lines, and repeat steps 8 and 9 again.

• Edit the Makefile in your build directory by commenting out the line

  HOWTOCOMPILE = DEBUG

  and un-commenting the line

  #HOWTOCOMPILE = OPTIMIZE

  Then repeat steps 9 and 10 from above. (You will also need to repeat step 8 if this is the first time the x-kernel has been built in OPTIMIZE mode on this platform.) This will build an optimized version of the x-kernel that does not include the trace statements that generated much of the output you saw before. Typically, you want to run the x-kernel in OPTIMIZED mode when you care about the performance measurements it generates.

• Edit graph.comp to include a different set of protocols. For example, instead of configuring TCP into your kernel, you could configure in UDP. This is done by replacing the lines

  name=tcp protocols=ip;
  name=tcptest protocols=tcp;

  with the lines

  name=udp protocols=ip;
  name=udptest protocols=udp;

  Then repeat steps 9 and 10 from above. You can also play with OPTIMIZE versus DEBUG mode, as well as the trace level while in DEBUG mode.

  Note that /usr/xkernel/user_level/build/Template contains various example_* subdirectories, each of which contains configuration files for various protocol stacks you can try. For example, try running an RPC protocol stack, or the MSP or SWP protocols.

• Repeat the entire process---steps 2 through 10---for some other Unix platform, for example, Linux on x86s rather than Solaris on Sparc.

• Implement a new protocol, and then configure an instance of the x-kernel that tests this new protocol. The best way to get started on this process is to copy an existing protocol into your build directory, and then edit this protocol to implement the desired functionality. We recommend protocol ASP as a template for doing this because it is so simple. ASP is implemented by the three files in /usr/xkernel/protocols/asp/asp.c, /usr/xkernel/protocols/asp/asp_internal.h, and /usr/xkernel/include/prot/asp.h. (Copy all three of these files to your build directory, and change their names to reflect the name of your protocol.) You will also need a test protocol that sits on top of your new protocol; we recommend /usr/xkernel/protocols/test/asptest.c for this purpose. Finally, you will need to edit graph.comp to configure your new protocol into the x-kernel .

  Of course, the hard work is to write the x-kernel code that implements the desired functionality. You will need to study the x-kernel Programmer's Manual [1] and Tutorial [2] to help you with this task. It will be especially helpful to study protocol ASP, which is described in detail in the Tutorial. We recommend you start with something simple, like changing the header format.