General Lites Information

First you'll need to create a /mach_servers directory. There are four things that need to end up here: startup, emulator, paging_file and mach_init. Copy the Lites server and emulator to /mach_servers from either /sbin (if you ran 'gmake install'), or from the emulator and server subdirectories of the Lites build directory.

At this point, the files you copied will probably have nice long names like emulator.Lites.1.x and startup.Lites.1.x.STD+WS+mach4. This is perfectly normal, but not what Mach is looking for. So either you can rename the files to be just 'startup' and 'emulator', or make a link.

        ln emulator.Lites.1.x emulator
        ln startup.Lites.1.x.STD+WS+mach4 startup

Now we need to create a paging file for Mach. Basically the paging file is just a large contiguous file that Mach can page to. Find a parition that's got lots of free space and do this: (where the count is how many megabytes you want the paging file to be)

	dd if=/dev/zero of=/usr/paging_file bs=1024k count=<#MB>

NOTE:

The device name is what the mach _KERNEL_ thinks it is, not what is in the /dev directory. This only matters for ST506/IDE drives, since they are 'hd' under mach, instead of the 'wd' that they are under *BSD. For SCSI drives the names are the same.

However, SCSI devices have their own quirks in that under *BSD they are generally given logical numbers (ie. sd0 is the first SCSI drive that was probed), however Mach assigns drive numbers according to the SCSI ID of the drive. So, sd5 under Mach could map to sd0 under *BSD, if it's the first drive on the chain.

So, anyway...determine what device corresponds to the partition that you made the paging_file on. So if /usr is /dev/wd0e under *BSD, you would do this:

	ln -s /dev/hd0e/paging_file /mach_servers

If you want to run mach programs (say the ones from user22), you'll have to get a mach_init binary and stick it in /mach_servers. mach_init comes with user22, so you can either install the user22-bin collection, or compile it yourself. You'll probably want to install the USER22 collection anyway, since it includes nice things like ps, machid, ms, mkill, etc. If you don't care about running mach programs on Lites, then you can just create a symbolic link to the standard init program:

	ln -s /sbin/init /mach_servers/mach_init

Now you need to create some devices for Lites. You can either run the MAKEDEV.lites that came with Lites-1.x, or create them by hand. To use MAKEDEV, do this:

	cd /dev
        sh .../sources/lites-1.x/MAKEDEV.lites time

If you're going to be using a network device, then you'll have to set up the system so that it tries to use the network interface name that Mach knows about, not *BSD (Lites dosen't do any device name mapping). So, for most releases of *BSD all you'll need to do is copy your /etc/hostname.* file. Supposing you're using a Western Digital card, you would do this:

      cp /etc/hostname.ed0 /etc/hostname.wd0

The only other thing you'll have to do is change the 'console' getty to actually look at the console and not some Virtual Terminal. This involves editing /etc/ttys to turn on the getty for the console device and turning off the one for the VT. At this poing Lites dosen't know about VT's and you'd be very dissapointed to reboot Lites and not ever get a prompt. On NetBSD-1.0 you should end up woth something like this:

#
#       from: @(#)ttys  5.1 (Berkeley) 4/17/89
#       $Id: ttys,v 1.6.2.1 1994/08/01 17:21:13 cgd Exp $
#
# name  getty                           type    status          comments
#
console "/usr/libexec/getty Pc"         pc3     on secure
#ttyv0  "/usr/libexec/getty Pc"         pc3     off secure

Now you're ready to boot Mach/Lites! Basically all you have to do is reboot your machine. At the boot prompt, type in the name of your mach kernel. The system should then load Mach into memory and start it running. It will then start Lites and you should eventually get a login: prompt. If you don't then something got messed up along the way; check everything again and if you really get stuck then try the mailing lists.

Namei macros in Lites

Lites does the following AFS-style namei expansions in pathname lookups:

@sys
expands to i386_lites, mips_lites, etc. per system basis
@cpu
expands to i386, mips, ns532, ...
@host
expands to the host name.
@bin
expands like @sys but per binary basis depending on what kind of a binary is being executed. The strings are i386_linux, i386_freebsd, i386_netnsd, i386_ux, mips_ultrix, etc. (Comments about the name choices are welcome: see exec_file.h)

The macros are expanded by namei. A path component must be the literal string (the macro must occupy an entire path component). Symlinks may contain namei macros.

The idea is to make it easier to have several sets of binaries on the same machine and to make switching between OSs easier. For example FreeBSD and NetBSD use the same names and paths for shared libraries. However, they are not compatible with each other. @bin may be used to distinguish (make a symlink containing @bin).

Another otherwise hard case is device numbers. Now you may have two /dev directories and choose on runtime. Create /@sys in Linux, and move dev there. ln -s /@sys/dev /dev. Create /i386_lites/dev and create the suitable devices there. Now both Lites and Linux will work (in this respect).

@host and @cpu might be nice sometimes so they got added too. But more than that I think is too much so no @uid, @pid, @date, or @whatever was added.

It can be argued that expansions should be done only in symlinks. This would be incompatible with AFS and DFS. How serious that would be is a matter of taste.