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.