Unix user-space (SunOS/Irix)

The behavior of an x-kernel running as a user task depends on the ``device drivers'' configured into the kernel. There are two categories of x-kernel device drivers: those that send real network packets (e.g., NIT in SunOS or IRIXETH in Irix), and those that send encapsulated network packets (e.g, SIMETH or SIMFDDI.) Real-packet drivers use platform-specific methods to access network devices, and are relatively straightforward to configure and use. (Be sure to see the manual page for the individual drivers in appendix B for specific configuration instructions.)

Simulated Drivers

Configuring the encapsulated-packet drivers can be a bit more confusing. (We refer to encapsulated-packet drivers as simulated drivers, and to x-kernels which use them as simulated x-kernels or just simulators. Simulated drivers sit at the bottom of a protocol stack, just like a standard device driver. Instead of sending packets directly to the device, however, they use the Unix socket interface (and thus the Unix implementations of UDP and IP) to send and receive packets. For example, if you implement IP and UDP within a simulated x-kernel, then the UDP packets produced by the x-kernel are, in turn, encapsulated in real UDP packets. This means that protocols and programs built on top of UDP in the simulator can only talk to their peers in other simulators; they cannot communicate with ``real'' versions of those protocols running stand-alone, for example, on a Unix machine.

Since a simulated x-kernel uses a connectionless UDP socket as its transport mechanism, more than one simulated x-kernel can be run on a single workstation. Because of this flexibility, the local IP address used by each simulator (the simulated IP address) is decoupled from the IP address of the actual workstation on which it runs (the real IP address). Configuration files for a simulated x-kernel must therefore indicate not only which UDP port should be used by the simulated driver, but also the binding between the real and simulated IP addresses for each simulated x-kernel.

Consider the following example ROM files (as described in section 13.2) for two simulated x-kernels:

    % cat client/rom

    simeth      port    3050
    #
    #           Sim. IP addr    Real IP addr     Real UDP port
    #
    arp         128.10.5.54     192.12.69.1      3050
    arp         128.10.5.23     192.12.69.1      3051


    % cat server/rom

    simeth      port    3051
    #
    #           Sim. IP addr    Real IP addr     Real UDP port
    #
    arp         128.10.5.54     192.12.69.1      3050
    arp         128.10.5.23     192.12.69.1      3051

The simeth entries indicate the real UDP port number which each simulated host will use to receive network packets. A unique port number must be used for each simulated host running on any given real processor. Simulated hosts running on different processors can use the same port number. (In this example, the two simulated hosts run on the same real processor (192.12.69.1) and use different UDP port numbers: 3051 and 3050.) Note that the name of the ethernet protocol appears exactly as it does in the graph.comp file.

For the arp entries, each line corresponds to a simulated IP host. The second field is the simulated IP host number, the third field is the actual IP host number where the simulator runs, and the fourth field is the simulator's UDP port number. Note that the simulated IP host numbers do not necessarily correspond to the real IP address of the machine on which the simulated host is running. Since ARP broadcasts are infeasible for simulated x-kernels, each simulator must be configured with an arp entry for each of its peers.

See the manual page in appendix B for more information on configuring the particular simulated driver you are using.

Running

As the result of configuring a kernel (section 12), a file named xkernel should exist in your current directory ( /usr/xkernel/build/yap).

While in this directory, create a sub-directory for each configuration you want to test. For example, if you are using a simulated x-kernel and want to start up two instances of the x-kernel, create two subdirectories, e.g., client and server. In each subdirectory, create a file named rom, containing configuration information as described above and in the man pages for protocols and device driver in appendices A and B.

Each simulated host runs as a separate Unix process. If you will be running multiple x-kernels and are using a windowing user interface, then you will probably want to start each process in a separate window. For each simulated host, open a shell command window, cd to the sub-directory that contains that host's rom file-e.g., cd client-and then type ../xkernel. To stop an x-kernel, type DELETE or CTRL-C.

SunOS caveats

We recommend building the sunos version of the x-kernel with a gcc earlier than 2.0, if possible.

Irix caveats

We recommend using the native IRIX C compiler for the multithreaded debugging support (not yet supported under GDB on IRIX), but a current version of GCC (2.3.3 and above) can also be used successfully. You may need to use GCC to build the utilities (compose etc), depending on which OS version you use.