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
from an
existing operating system
the code 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.
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 or unimport 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