General Lites Information

Last updated: March 15, 1996


Links to more information
Configuration Options
Lites Special Devices
Installing on the x86
Namei macros in Lites


Lites is a 4.4 BSD Lite based server and emulation library that provides free unix functionality to a Mach based system. The latest Lites release is lites-1.1.u3.

Links to more information

Configuration Options

Explanation of lites configure options used:

This adds the +mach4 option to the Lites configuration, which causes Lites to look for includes where Mach4 puts them. It will eventually turn on Mach4 specific features.


This adds the +slice option to the Lites configuration, which includes support in Lites for `slice' device names. This was first included in lites-1.1.u3. You of course need a kernel that also understands slice names, like Mach4 UK22. This only makes sense on the x86.


Specifies the target system to compile for. This used to be the --host= option in Lites-1.1.


This adds +DEBUG to the Lites configuration, which turns on various sanity checks in the server.


Specifies where Lites will be installed, and also where it looks for include files/libraries. For best results this should be where your mach programs/libraries are.


This specifies where the source is, only needed if you're not running configure from the source directory.


This allows you to set the server configuration. The default is STD+WS; see conf/MASTER.h and other MASTER files for more information.


adds -DGPROF and -pg and uses libmach_sa_p.a etc.

Lites Special Devices

There are two sets of special Lites devices: those for mapped time and X11. If you're running lites, you'll probably want to create the time devices, but you only need the X11 ones if you're going to be running X on Lites.

Devices for mapped time:

mknod time c 25 0
mknod timezone c 26 0

For those of you running Lites on the x86, you'll also be interested in the XFree86 special devices.

Devices for Mach version of XFree86:

mknod iopl c 22 0
mknod kbd c 23 0
mknod mouse c 24 0
Actually you'll probably want to use something other than 0 for the minor numer of the mouse, since that's what determines what sort of mouse you've got connected.

Here's a snippet from the Mach XFree README file about mice:

Mach supports several kinds of external mice, the logitech three button mouse, the microsoft two button mouse, the PS2 mouse, and the logitech mouseman mouse. We do not support any kind of bus mouse. The way you indicate the mouse type and com port is with the mouse device minor. The value you set the minor to is computed by the formula:

  < type > * 8 + < com port >
< com port > is 0, or 1 or ... depending on which com port you plug your mouse into. (Some architectures prefer to make com0 the modem line.)
     < type > is:

       0       for logitech mouse
       1       for microsoft mouse
       2       for ps2 mouse
       3       for no real mouse at all
       4       for logitech mouse man (M+ or V type)

Installing on the x86

Since you're actually going to be running Lites, I'll assume that you're not running Linux on an i386 box, which means that you're running some variant of BSD. If you haven't already, copy a Mach kernel into / so that you can boot from it.

  • Populate /mach_servers w/server and emulator.

    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
  • /mach_servers/paging_file

    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>
    The tricky bit comes next, since you don't actually have a paging_file in your /mach_servers directory where you really need it. Now you need to make a link in /mach_servers to wherever your paging_file is. However, the mach kernel dosen't know much about filesystems, so you have to prepend the device name of where it is.


    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
  • /mach_servers/mach_init

    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
  • Lites special devices.

    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
    There is also some X related devices, but you only need those if you're going to be running X under Lites. You can run 'MAKEDEV.lites X11' to make them, or 'MAKEDEV.lites all' to create both sets. Check the Appendix (or just be adventurous and look at MAKEDEV.lites) for creating the devices by hand.

  • Networking setup.

    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
    If you're using FreeBSD-2.0, you'll need to go into /etc/sysconfig and add the Mach ethernet device to the list of interfaces to try and configure at boot.

  • /etc/ttys

    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 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
    The FreeBSD-2.0 /etc/ttys file is very similar.

  • Booting Mach/Lites.

    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

    Shamelessly stolen from the Lites homepage; Johannes Helander wrote this:

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

    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.

    Mike Hibler <>
    Stephen Clawson <>