SAL: stand-alone layer

A stand-alone program is one that runs without operating system support. SAL is a chunk of code that handles such chores as initializing the cpu/mmu and operating the devices. A SAL client program links to SAL to form a complete stand-alone program. An alternate definition of a stand-alone program is that you have to reboot to run a different one.

SAL is created by extracting code from an existing operating system that boots and controls the hardware. It does not include a scheduler, virtual memory, file system, users or system calls. SAL does include a debugger and enough networking for a tftp client. The intention is that the SAL client program will implement an operating system to provide the services explicitly left out of SAL.

Generic SAL Services

The major SAL ``service'' is to boot the machine and call 
	run_program()
which represents the SAL client.

For any platform, SAL includes the TTD debugger for network debugging and the tftp client . These services are supported by a polling network interface native to SAL.

Sample SAL Client

The stand-along layer allow clients to provide a small set of routines, largely for TTD support. The simplest sal client just provides null implementations of these routines. Such a client to appear in the standalone directory .

Digital Unix SAL

For the DEC alpha platform, SAL is extracted from the sources for Digital Unix (nee OSF/1). It is configured and built in the same way as Digital Unix. The configuration happens in the conf directory.

Most of the alpha sal files are copied from the regular Digital Unix source tree (that tree is the DIGITALUNIX directory as set in spin/make.conf). At UW, DIGITALUNIX is /afs/cs/system/os/osfsrc/OSC320/src/kernel. To make a diff file, be sure to give diff the files in the right order: 

	cd spin/kerenel/sal
	diff /afs/cs/system/os/osfsrc/OSC320/src/kernel/foo/bar.c foo/bar.c > foo/bar.c.diff
If this is a new diff file, remake the dependency file. Once the diff file is the dependencies, make will apply the diff file whenever it changes before compiling the source file. 
	cd spin/kernel/sal
	gmake deps
After changing or adding a diff file, check it in to cvs as usual.

Digital Unix SAL is built in several stages. Ideally it would all be built last. Unfortunately files in spincore include several .h files from sal, so an early stage builds enough of sal for those files to exist.

gmake configure
The first stage of building sal is configuration. The main Makefile imports, from the DEC source tree, parts of the build environment needed for configuration (see the files variable in the sal/Makefile). Next it runs "config SPIN" to create the SPIN directory and generate the sources that live there. Finally it imports the include files needed by spincore (see the spincorefiles variable in the sal/Makefile).
gmake all and gmake SPIN
After the sal client (spincore and start) are built, sal can be built and linked with the client to form the boot image. For SPIN, the bootp image is spin.boot and the image for disk boots is spin_kernel.sys.
gmake deps
This command regenerates the dependecies file. The dependencies file is central to the scheme that imports files from the DEC sources. It is part of the source tree and lives in the conf directory. It contains all the dependecies for the SPIN and DRIVER (see below) build trees.
gmake import and gmake unimport
This will import (copy and diff if needed) or unimport (remove the copied files) all the sal sources borrowed from Digital Unix.

SPIN Client

SAL was created for the SPIN client. The run_program() routine is located in the SPIN initialization sources. That code starts up the SPIN core services which supports scheduling, memory management and SPIN extensions.

DRIVER extensions

SPIN uses several chunks of code from Digital Unix as extensions including the TCP stack and the CAM driver. These are also built in this tree to keep the includes together and since the machinery is all here for borrowing the DEC sources.

Extensions in the user tree have Makefile commands to come into this tree and build the DRIVER tree. To build by hand, use the DRIVER target gmake DRIVER

becker@cs.washington.edu