Multics Technical Bulletin MTB-631
Bootload Multics Task List
To: Distribution
From: Keith Loepere
with an introduction by Tom Casey
Date: 08/23/83
Subject: Bootload Multics Task List
Introduction
This MTB contains a task list for Bootload Multics. For
each task, it provides a brief description, a time estimate,
schedule and status information where known.
The purpose of this MTB is to present a complete picture of
the magnitude of the effort involved and the directions that
design discussions are taking, and to indicate our current
implementation priorities. Tasks have been scheduled to provide
capabilities required in Orion and Dipper test cells and System M
exposure prior to FCS. It is expected that the BOS-less version
of bootload Multics will be released in MR11 in 4Q84.
In the interest of timely publication, technical details,
including justification for design decisions, have been omitted.
See MTB 598, rev 2, (not yet completed) for more technical
background.
The tasks listed below, if all implemented, would provide
complete replacement for all BOS functions. However, the words
"optional" or "not planned" in the status column indicate doubt
as to when or if these functions should be provided. Comments on
the need for those functions, as well as on the schedule, time
estimates and overall design, are invited. They may be entered
in the Bootload_Multics forum.
_________________________________________________________________
Multics project internal working documentation. Not to be
reproduced or distributed outside the Multics project.
Multics Technical Bulletin MTB-631
Bootload Multics Task List
bootload Multics list of effort status start stop
tasks [means FW FW
already
expended]
----------------------------- --------- ------ ----- ----
- boot from tape [several done
years]
Currently, Multics is booted from a bootstrap system known as
BOS. Since BOS will not function on new hardware and is made
obsolete thereby, it is necessary to be able to boot directly
from a Multics system tape (MST) using the IOM boot function.
- bootload command [3 weeks] done
environment
During Multics initialization, Multics shall be able to pause
before activating the file system to permit activities such as
saving disk contents, examining the software, etc, which was
previously performed by BOS. This requires a command environment
in which to run command programs to perform these functions. The
various functions to be performed within this command level
constitutes the majority of the following list of items.
- configuration file editor [3 weeks] done
(except for a possible conversion
to use bootload qedx)
One of the functions required at bootload Multics level is to be
able to enter and modify the description of the hardware that
will be used for Multics. A program must be written to convert
between a user description of the hardware and an internal
description. This program replaces the BOS config function.
- text editor [2 weeks] done
A text editor must be made available for bootload Multics so that
automatic system startup procedures (exec_com's) and other ascii
text may be edited. This involves modifications to qedx, one of
the standard editors, for operation in the bootload environment.
This program replaces the BOS edit function.
- bootload file system [2 weeks] done
A primitive file system must be provided to hold the automatic
system startup procedures and other ascii text to be used within
bootload Multics. This also requires commands to init this file
system, delete, rename and list the files, and also to print
them. System conventions for multiple file access (star
convention) shall be used. These files will also be writable
Multics Technical Bulletin MTB-631
Bootload Multics Task List
from within normal Multics operation. This facility replaces the
BOS delete, list, rename, and edit print functions.
- exec_com facility [2 weeks] done
There shall be a method for providing operator invokable system
startup procedures. This facility will be compatible with
version 1 exec_com's within normal Multics operation. This
facility replaces the BOS runcom, if, quiet, ready, tty and write
functions.
- system clock setting [1 week] done
A method needs to be provided to set the system clock. This
replaces the BOS time function.
- automatic creation of [1 week] done
required disk partitions
Since bootload Multics is to run before the Multics file system
is active, it needs its own reserved areas of disk (partitions)
to use for storing files and other information. To remove the
burden for sites of having to reformat their disks to contain
these areas, a program is to be provided that will automatically
create them when bootload Multics is first run at the site.
- multiple disk copy program [3 weeks] done
A program shall be provided for operation within bootload Multics
that can copy the contents of disk packs onto other disk packs.
If possible, several such copies should be allowed to proceed
concurrently. This program replaces the BOS save copy function.
- program to save crash-to- 4 weeks required 332.1 335.5
able bootload Multics to disk; saving portion written,
toehold program to save/restore memory not tested
and toehold creation
Currently, when Multics crashes or shuts down, it returns to the
BOS toehold, which first saves low memory to disk and then loads
a BOS core image. The bootload Multics equivalent of the BOS
core image is generated by running early Multics initialization.
A program must be written to save this image appropriately to
disk, in a state such that it can be loaded back into memory and
resume execution at a known point. Also, the bootload Multics
toehold must be written. This is a very primitive program that
can be guaranteed to operate, in spite of the failure (crash) of
Multics, to write the state of (some of) Multics memory out to
disk and to read in the image of bootload Multics saved on disk.
This program (the toehold) requires a program to generate the
device control lists necessary to perform this i/o.
Multics Technical Bulletin MTB-631
Bootload Multics Task List
- Multics crash/shutdown 2 weeks required 336.2 338.1
mechanism
The mechanism by which Multics invokes the toehold to perform a
crash or shutdown needs to be written.
- bootload Multics shutdown 3 days required 338.2 338.4
For compatibility with BOS, bootload Multics needs a way to
shutdown to BOS, if bootload Multics was booted from BOS as
opposed to the IOM. If bootload Multics was booted from the IOM,
this will replace the BOS die function.
- automatic procedure 1 day required 338.5 338.5
specification
It is desirable to be able to specify what the system should do
when it crashes or is shutdown. At crash or shut down time, BOS
simply performs the next step in its procedure (runcom) after the
step that booted the system. Bootload Multics, however, will not
do this and will need a way to specify the procedure to run at
crash or shut down. This procedure will be specifiable from
either bootload Multics or normal Multics operation.
- toehold/flagbox variable 2 days required 339.1 339.2
management
The flagbox area of the toehold is used to communicate
information between normal Multics operation and bootload Multics
operation. Both Multics service and bootload Multics commands
need to be provided to manipulate this area. This replaces the
BOS flag and the Multics flagbox facilities.
- Multics restarting 1 week required 339.3 340.2
For testing purposes, Multics is told to shutdown to bootload
Multics. Tools within bootload Multics are used to
examine/manipulate the saved Multics image. Multics is then
restarted, possibly after modifying machine conditions. This
restart mechanism needs to be written. This replaces the BOS
contin and go functions.
- emergency shutdown 2 days required 340.3 340.4
When Multics crashes and after any dump is taken, it is necessary
to perform a Multics function known as emergency shutdown. This
operation tries to migrate to disk the pages of files found in
memory, thus providing a more consistent state to the files than
would exist otherwise. A mechanism by which bootload Multics
will invoke this Multics function needs to be written. This
replaces the BOS esd command.
Multics Technical Bulletin MTB-631
Bootload Multics Task List
- disk saving to tape [5 weeks] written, 340.5 343.4
3 weeks needs testing,
integration
A program must be provided to save the contents of disks to tape
for backup purposes. It is desirable for this program to save
more than one disk at a time. This activity includes the work to
provide tape support for bootload Multics, as well as the base
level for support of other device drivers needed by many of the
other activities. This function replaces the BOS save function.
- disk restoration from tape 3 weeks required 343.5 346.4
A program must be written that can restore the contents of a disk
from previously saved tapes. It is desirable for this program to
restore more than one disk at a time. This replaces the BOS
restor function.
- warm boot from disk 1 week required 346.5 348.1
Multics is initially booted (cold booted) from the Multics system
tape (MST). The tape is then normally demounted. To allow
Multics to be booted again after a shutdown or crash, especially
in cases of unattended service, bootload Multics shall save the
remaining contents of the MST into a disk partition. The actual
booting of Multics from bootload Multics will take place from
this partition. The program to copy the tape into the partition
and modifications to the remainder of initialization to boot from
the partition are needed.
- Multics address space 2 weeks required 348.2 350.1
access
A package must be written to access Multics segments in the crash
image; it is used by the dump/patch facility and the facility to
provide a dump. This facility needs to be sufficiently robust to
deal with invalid tables, etc. in the Multics crash image. This
replaces the BOS apnd and sstn functions.
- dump/patch facility 3 weeks+ required 350.2 402.5
A dump/patch facility that operates on memory addresses in the
crashed system, virtual addresses in the crashed system, and disk
addresses is needed. This will replace the BOS abs, dump and
patch facilities.
- disk dump program 4 weeks+ required 403.1 406.5
The program that examines the saved Multics crash image and
produces a dump image on disk for dump analysis tools must be
written. The disk dump must be compatible with the already
Multics Technical Bulletin MTB-631
Bootload Multics Task List
existing dump analysis tools. This replaces the BOS fdump
function.
- firmware loading 2 weeks required 407.1 409.1
Mechanisms must be provided for loading firmware into the various
controllers. The bootload tape controller is loaded
automatically; the main disk controller is loaded as part of a
dialog during booting of bootload Multics. The rest will be
loaded automatically by a program that scans the configuration
file. This will replace the BOS fwload function.
- break key 1 week required 409.2 410.1
A method must be provided to interrupt a mistakenly started
operation. This requires a mechanism within the operator's
console software to recognize when the operator hit a break, and
a mechanism by which this signal gets sent to the program being
interrupted.
- early initialization dumps 4 weeks required 410.2 414.1
The debugging facilities present within bootload Multics cannot
be used until bootload Multics becomes operative. Bootload
Multics cannot be used to examine failures in booting itself. It
is therefore desirable, especially for the Orion project, to
provide a method of dumping the memory image of bootload Multics
to tape when a failure occurs in early initialization. This
program must run in a primitive environment and be written in
assembly language. A Multics program must be written to
understand this tape.
- printer support 2 weeks required 414.2 416.1
A driver will be provided that allows arbitrary output destined
for the operator's console to be routed to a line printer. Error
messages will continue to go to the operator's console. The
Multics driver must be modified for bootload use. This would
replace the BOS prt function.
- operator's console alarm 1 day required 416.2 416.2
A mechanism is needed so that automatic crash procedures can ring
the operator's console alarm. This would replace the BOS write
alert function.
- cache examine program 3 days optional 416.3 416.5
This would replace the BOS abs cache function.
- disk volume interpretor 2 days optional 413.1 413.2
Multics Technical Bulletin MTB-631
Bootload Multics Task List
A desirable tool would be one that displayed information about a
disk pack. This would replace the BOS rdlabl function.
- ready_on, ready_off 1 day optional 417.1 417.1
Commands may be provided to turn on and off the message that
bootload Multics prints after completing any function. This
would replace the BOS ready function.
- file_output, revert_output 1 day optional 417.2 417.2
So as to make it easier to peruse what would otherwise be a large
amount of printed output, a command will be provided to route
output destined for the operator's console into a file for
perusal with the text editor.
- operator prompting 1 day optional 417.3 417.3
A mechanism may be provided to control the prompt given to the
operator when waiting for input. This would replace the BOS
prompt function.
- disk test 1 week optional 417.4 418.3
A tool may be written to test a disk by writing/reading various
test patterns. This would replace the BOS test function.
- dump tape contents 1 week optional 418.4 419.3
It may be desirable to provide a program to dump the contents of
a tape to the console. This would replace the BOS label, print
and taped functions.
- memory save/restore to tape 1 week not planned
It may be desirable to provide for the saving/restoring of all of
memory to tape. This would replace the BOS core function.
- generation of a new MST 1 week not planned
It may be desirable to provide a program that can generate a new
MST from within bootload Multics. This would be the equivalent
of the BOS bostap function.
- mpc dump 2 weeks not planned
A program may be provided to dump the contents of mpcs from
within bootload Multics. (The Multics software that performs
this function is not appropriate for bootload Multics.) This
would replace the BOS mpcd function.
Multics Technical Bulletin MTB-631
Bootload Multics Task List
- save to disk 2 weeks not planned
A program may be provided to save disk contents onto other disks
in packed fashion (as opposed to a straight copy). This would
replace the BOS save disk function.
- iom channel test 3 weeks not planned
A program may be provided to perform arbitrary i/o tests on any
iom channel. (No appropriate Multics mechanism exists.) This
would replace the BOS tstchn function.
- card reader support unknown not planned
A driver may be written to allow input from cards within bootload
Multics. (The Multics driver is not appropriate for bootload
use.) This would replace the BOS cards function.
- card punch support unknown not planned
A driver may be written to allow bootload Multics to output to
cards. (The Multics driver is not appropriate for bootload use.)
This would replace the BOS punch function.
- loading new commands very hard not planned
A facility may be provided to load new commands into bootload
Multics while it is operating, instead of loading a new MST.
This would replace the BOS loaddm function.
- FNP support very hard not planned
A driver may be provided so that bootload Multics may communicate
with the FNP. This would be done to allow for dumping of the
FNP. (The Multics driver is not appropriate for bootload use.)
This would replace the BOS dmp355 and fd355 functions.
- formatting disk packs very hard not planned
A program may be provided to format disk packs from within
bootload Multics. This is currently done by t&d's, and also once
Multics is operating. (The standard disk driver does not support
the needed operations.) This would replace the BOS fmt function.