Unix User Level (SunOS/Solaris/OSF/Irix/Linux)

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., ETHPKT in Linux and 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 A.)

Simulated Drivers

Configuring the encapsulated-packet drivers can be confusing. (We refer to encapsulated-packet drivers as simulated drivers, and instances of x-kernel s using them as simulated hosts.) 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 user_level 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 x-kernel can only talk to their peers in other x-kernel s; they cannot communicate with ``real'' versions of those protocols running on a Unix machine, for example.

Since a user_level x-kernel with a simulated driver uses a connectionless UDP socket as its transport mechanism, more than one such x-kernel can be run on a single workstation. Because of this flexibility, the local IP address used by each kernel (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 user_level 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 x-kernel .

Consider the following example ROM files (as described in Section 12.4) for two user_level x-kernel s.

    % 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 x-kernel runs, and the fourth field is the x-kernel '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 hosts, each x-kernel must be configured with an arp entry for each of its peers.

See the manual page in Appendix B for more information on configuring a specific simulated driver.

Running

As the result of configuring a kernel (Section 12), a file named xkernel should exist in your build directory.

While in this directory, you should create a sub-directory for each x-kernel instance to be tested. For example, if you intend to start up client and server instances of a user_level x-kernel , create two subdirectories, e.g., client and server. In each subdirectory, create a file named rom, an example of which can be copied from /usr/xkernel/user_level/build/Template. The ROM files should contain configuration information as described in Section 12.4, and in the man pages for protocols and device drivers in Appendix A.

Each simulated host runs as a separate Unix process. To run multiple x-kernel s using a windowing user interface, you should 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 type ../xkernel. Use DELETE or CTRL-C to stop an x-kernel .