[TUHS] Bootstrapping UNIX - how was it done

[Noel Chiappa via TUHS]

    > From: Adam Koszek

    > How was UNIX bootstrapped in the early days?

How early? The PDP-7? :-)

On _very_ early machines, it was quite common to have to manually enter the
initial small program for bootstrapping, using the toggle switches on the
front console (which allowed one to examine and store memory locations), to
read in the system from wherever it was stored.

Note that _very_ early on, the initial software load would have been on a
reel of punched paper tape, not read in from the disk. (I think some early
PDP-11 UNIX versions did that, IIRC.)

Soon after the PDP-11 arrived, it had available a very small bootstrap ROM -
an array of diodes! Diode in = 1, diode out = 0. (I am not making this up!
Image of one here:

  https://gunkies.org/wiki/BM792_ROM

You can read the program off the image! I have actually programmed one of
those - with a soldering iron!) Most of the -11's I worked with had that, or
a later ROM chip ROM - but not all, and had to be toggled.


The software aspect was a whole different world. The DEC-supplied bootstrap
program (in ROM) loaded block 0 from the disk - which for UNIX contained a
small elegant program, described here:

  https://gunkies.org/wiki/Installing_UNIX_Sixth_Edition

which was prepared too load in the entirety of a normal UNIX-format binary
file from any place in the file system, and start it. (I used that capability
to load ring network interface diagnostics I wrote.)

>From there:

  UNIX kernels consists of a number of smallish relocatable binary modules
  which are statically linked into a large object code image; during booting,
  that image is loaded into memory and started. After the usual initialization,
  the '0th' process (which in V6 has the task of swapping processes in and out)
  is hand-crafted; if then 'forks' into two, using the standard UNIX fork()
  system call (which creates a 'clone' of the existing process).

  The second process then runs a tiny program (the binary for which is built
  into the kernel) which does an 'exec()' system call, to read in and run
  "/etc/init". That process/command then does another fork(), and the child
  process from that exec()'s the shell (command interpreter, in "/bin/sh").

(Which was all very simple, compared to some contemporary operating systems.
To explain how Multics booted _did_ take a book - "Internal Organization of
Multics System Initialization; Program Logic Manual", AN70:

  https://bitsavers.mirrorservice.org/pdf/honeywell/large_systems/multics/haley/AN70_Feb75.pdf

In its defense, the exact same magtape could be used to boot _any_ Multics
system, no matter what its physical configuration; basically, a custom kernel
was linked together during the boot process.)


    > What editors were used for early B, B+, C and early kernel?

Some version of 'ed', I would expect.


    > For bootstrapping, some aspects must have been easier: ... But some
    > aspects must have been hard - after hitting some level of complexity
    > with sizable programs, debugging things from the long log of teletype
    > printout must have been interesting

Most programs could be debugged under the OS, and there were tools available
to help with that. In early UNIX versions (before V6; V5 didn't seem to have
ptrace()) debugging was not interactive; the system could produce - on
demand, or after a fault - a 'core dump' of the process, stored on disk, in
the file system. 'db' could be used to poke around in that.

Debugging the OS was a whole different trip. I gather that core dumps were
the usual mechanism at Bell, etc. (At MIT, where we did a lot of OS work, to
add networking, we grumped about that. The _other_ OS's in use in the Tech Sq
building - ITS and TOPS-20 - had debuggers integrated into the OS, so one
could set breakpoints, single-step them - all symbolically. On UNIX, nothing
doing.)

We should have used printf()'s - maybe the guys at Bell used them, but we
never did at MIT. (I only started to use them doing retro UNIX OS work, after
I retired.)

>From early versions of UNIX (I'm too lazy to check, but I think it started at
the first versions) there was a manual 'core dump' tool. Stop the machine, and
start it (via the front console) at a magic location, and it would write the
entire contents of main memory, along with some key registers, onto a
magtape. See:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m40.s

at label "dump:". (Our machine at MIT didn't have a magtape drive, so we
wrote code to dump it into a reserved partition, on the RK drive we used for
swapping.) With that dump tool, you couldn't see processes that were swapped
out at the time the dump was taken, but it usually saved enough to poke
around, and thinking hard, work out what had gone wrong.


Feel free to ask for details of any part of this!

	Noel