Xref: utzoo unix-pc.general:6874 comp.sys.att:11208
Path: utzoo!attcan!telly!eci386!jmm
From: jmm@eci386.uucp (John Macdonald)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: kit posting, what I'm working on
Message-ID: <1990Dec17.165934.1407@eci386.uucp>
Date: 17 Dec 90 16:59:34 GMT
References: <1990Dec12.065224.10906@i88.isc.com> <111@limbic.ssdl.com> <1990Dec14.060413.13515@i88.isc.com>
Reply-To: jmm@eci386.UUCP (John Macdonald)
Organization: Elegant Communications, Inc.
Lines: 75

In article <1990Dec14.060413.13515@i88.isc.com> botton@i88.isc.com (Brian D. Botton) writes:
|>>worth the trouble to put a monitor program in so you can hack at the lowest
|>>level?
|>
|>Sounds neat too...  I wonder how many people would actually find this useful
|>though.
|
|  Yea, sound neat, but I don't know who would use it.  Maybe a better answer
|is to put in the screen I/O and pair down what the ROM can do.  Such as:
|
|	1. Test MMU
|	2. Test memory
|	3. Read floppy block x
|	4. Write floppy block x
|	5. Read HD block x
|	6. Write HD block x
|
|  This way, if you want, you can get blocks onto and off of the HD and put
|them somewhere useful, i.e., the floppy, for later perusal on a system with
|tools like od.

How about: backup and restore, which copy a disk partition to
or from a sequence of tapes or floppies.  This allows making
a full image backup of a system.  If needed, it can be restored
on a blank (but formatted) disk without having to install an
OS on the disk and then trying to not trip over itself when it
restores over top of itself.  Restoring the root partition is
trivial in this fashion.  I had these functions in the PROMs I
wrote for another system.  PROM-based backup and restore are
extremely valuable.  (It was more valuable in that system, which
always had a 40 Meg tape drive for making the backups - they are
a lot better than floppies for this purpose.)

The same code that does the floppy sequencing for backups could
be used to allow loading an OS (or test program) that is too big
to fit on a single floppy.

(Imagine a kernel with a compiled-in, initialized 1.5 Meg ram
disk.  You could boot from floppy with a system that had a
built-in tape driver, a sufficient file system for repair
activity (fsck, etc., but not totally stripped down to the bare
bones), and would still be able to mount a floppy file system.
Actually, this system is not as valuable as it sounds - the PROM
backup capability allows you to backup the non-working system,
reinstall a working system, restore the backed-up stuff to an
alternate partition to be fixed with a full running system, and
then copy it back into its proper place with the PROMs).

In a later message Brian mentions being able to use bigger PROMs
and having a huge amount of available space.  Great.  How about
putting fsck into the PROMs, allowing the output log to be saved
on a floppy for later examination.  I'd love to have the "normal"
startup sequence default to something like the following:

    the PROM code checks for a floppy
	if present and there is a magic flag of some sort
	    the PROM continues to run without loading from the floppy
	    the PROM resets the magic flag
	    the PROM runs fsck on a sequence of file systems given
		on the floppy, using arguments specified on the
		floppy, the output of fsck gets stored on the floppy
	    the PROM boots the default system from disk
	    the startup code collects the fsck log and sets the magic
		flag again

This would allow the default startup procedure to be fairly safe
while still being automatic.  The log from fsck is not lost, so
file that have problems can be seen.

Putting fsck into the PROM is not a trivial proposition, it would
require writing a set of functions that provide the system call
capabilities that fsck expects.
-- 
Cure the common code...                      | John Macdonald
...Ban Basic      - Christine Linge          |   jmm@eci386