Next: Unix user-space (SunOS/Irix) Up: Running a Kernel Previous: Protocol Tables

ROM files

To support run-time options for protocols and various subsystems, the x-kernel provides the notion of a ROM file. When a protocol instance or x-kernel subsystem initializes, it typically scans a list of user-provided options in the ROM file to see if it should adjust its default parameters for that particular instantiation. ROM options are used for a variety of purposes, such as providing initial values for databases, specifying numbers of network shepherd threads, and providing IP gateway information.

Each ROM file entry consists of a single line. The first field in each line specifies the particular protocol or subsystem that should interpret that line. The rest of the fields are specific to that particular protocol or subsystem. Comments can be added following a #. As an example:



      #
      # Example ROM file
      #

      simeth 	port  1234

      arp 192.12.69.49  192.12.69.1 1234
      arp 192.12.69.45  192.12.69.1 9876

      prottbl /usr/xkernel/etc/prottbl.nonstd

The SIMETH protocol will interpret the first line, the ARP protocol will interpret the second and third lines and the protocol table subsystem will interpret the last line.

The exact method for providing ROM files is specific to the individual platforms and is documented for each platform in section 13.

Protocols which provide ROM file configurable options will describe the format of these options in their man pages in appendix A.

ROM File Generators

The ``rom'' file used during x-kernel initialization has a cryptic format that can be difficult specify and maintain manually. The genrom.sh and genrom2.sh utility programs can ameliorate the problem by using a ``rom'' file template and expanding it into one more files for use with testing configurations. This is especially helpful for use with the simeth (see appendix B) and simsimeth (see appendix A) protocols, or in testing configurations where an ARP server is not available.

The genrom.sh utility generates rom files for the x-kernel from prototype files. It includes information about the addresses of hosts specified by name on the command line. For example, using the prototype rom file ``romgen'' with the three lines:


simeth
arp
dns

and the command genrom.sh romgen umb lei, two rom files are produced, rom.umb.1 and rom.lei.2 with the contents


rom.umb.1:
simeth 4724
arp 192.12.69.97 192.12.69.97 4724
arp 192.12.69.116 192.12.69.116 4725
dns umb 192.12.69.97
dns lei 192.12.69.116

rom.lei.2:
simeth 4725
arp 192.12.69.97 192.12.69.97 4724
arp 192.12.69.116 192.12.69.116 4725
dns umb 192.12.69.97
dns lei 192.12.69.116

The ``dns'' lines refer to the simulated IP addresses for simeth and simsimeth files. See the manual sections on simsimeth and simeth for detailed explanations of the simulated address numbers.

The genrom2.sh utility generates two rom files for the x-kernel from two prototype rom file files. This is generally used for developing rom files to be used between a machine running simeth and a machine running simsimeth. For example, given two prototype rom files, romgen1 and romgen2,


romgen1:
simeth
arp

romgen2:
ethdrv/SE0 priority 200 
arp/lower
eth/upper mtu 1440
simsimeth
arp/upper

The command genrom2.sh romgen1 romgen2 umbra moz produces two rom files, rom.umbra.1 and rom.tch.2 with contents:


rom.umbra.1:
simeth 1690
arp 192.12.69.97 192.12.69.97 1690
arp 192.12.69.99 192.12.69.99 1691

rom.tch.2:
ethdrv/SE0 priority 200
arp/lower 192.12.69.97 192.12.69.97 1690
arp/lower 192.12.69.99 192.12.69.99 1691
simsimeth 1691
eth/upper mtu 1440
arp/upper 192.12.69.97 c0:0c:45:61:06:9a
arp/upper 192.12.69.99 c0:0c:45:63:06:9b

CAVEATS

Both genrom.sh and genrom2.sh work by running the Unix command ``arp'' to get the ethernet addresses of the machines. The target machines must be running in order to get this information. If they aren't running, a bogus ethernet number will be used as a substitute. There is a further complication in that you cannot get the ethernet address of the machine you are running on. To overcome this failure, the programs will try to run ``arp'' on another machine using ``rsh''. The default machine is ``cheltenham'' (this default should be changed for sites other than University of Arizona); if you do not have an account on that machine, you will need to set the environment variable ROMGEN_HOSTto some other host on your network where you can execute the command /usr/etc/arp via the ``rsh'' command. It may be necessary to establish a .rhosts file on the ROMGEN_HOSTfor this to work properly.

To get the arp addresses into the routing table, each host is probed using ``ping''. Output from ``ping'' indicating whether the host is dead or alive will be printed on stdout.

It is important that the arp lines come after the simeth or simsimeth line they are related to. I.e., in the romgen2 file above, the arp/lower line generates arp entries appropriate to a real ethernet because there has been no previous mention of a simeth or simsimeth protocol. After the ``simsimeth'' line, the next arp line produces entries appropriate to the simsimeth protocol.

The port numbers used for encapsulating traffic sent over UDP are assigned at random. You can override this by assigning a base number in decimal using the environment variable ROMGEN_BASE_PORT.

Normally the simeth arp lines use the same address for the real and simulated host address. If you use the same host twice on the command line (e.g. genrom.sh romgen umb umb), then the second arp entry will use a host address of ``192.12.69.1'', and further redundancies in host names will simply result in incrementing the fourth component of the network address. This might cause clashes with other host names. You can change the base number used for assigning the fourth component using the environment variable ROMGEN_FAKE_IP_BASE.

Another problem occurs when one real host is used to simulate more than one test host. The ``dns'' lines that are generated must use a simulated host name. This is achieved by attaching a number to hostname, i.e. genrom romproto umb umb will result in dns records for ``umb'' and ``umb2''. Currently, this is only detected when the hostname occurs consecutively on the command line, i.e.

genrom romproto umb ush umb

would not be handled correctly; it would be necessary to edit the generated rom files to correct the dns lines for the second occurrence of ``umb''.

Only the first word on each line is examined in the prototype file; if you have ``arp xxx yyyy'' or ``dns name number'' lines, they will be interpreted exactly as if they were simply ``arp'' or ``dns''.



Next: Unix user-space (SunOS/Irix) Up: Running a Kernel Previous: Protocol Tables


Tue Nov 29 16:28:56 MST 1994