The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [TUHS] Paper discussing Unix boot process?
Date: Tue, 16 Apr 2019 08:52:37 -0400 (EDT)	[thread overview]
Message-ID: <20190416125237.333B918C0BE@mercury.lcs.mit.edu> (raw)

    > From: Charles Anthony

    > The Multics System Initialization Program Logic Manual. 139 pages of
    > somewhat detailed information. 

I was going to mention the Multics init PLM! :-) Needless to say, it's
probably not a good candidate for the original goal - a document describing
how an OS boots - it's simply too complicated for ordinary mortals! (Reading
it makes _my_ head hurt!) There are a couple of reasons it's so complex.

Multics is not a monolitic OS, the way most versions of Unix are (although I
gather this is no longer quite true of Linux); the OS isn't this large blob
of bits you load into memory and start. Its structure makes heavy use of the
segmentation model supported by the hardware. Moreover, although the first
segments loaded aren't paged, many of the later ones are. (This makes sense
in the context of the times; with limited core main memory, you wouldn't want
to devote massive chunks of main memory to have the entire OS always
resident.)

However, this all makes for a more complex booting process; the standard
Multics boot tape (a Multics System Tape) contains many modules, which get
linked in individually at boot time. (In V6 terms - the version I'm most
familiar with - it's as if a Unix boot tape contained 'lib1' and 'lib2', and
the bootstrap included a linker to build the OS binary in memory.) And in fact
the modules come in in tranches, and some of the earlier one are available for
use in loading later tranches (e.g. paging).

This does have some advantages, though; e.g. the MST is the same for all
Multics machines (including the initial boot of a new machine); the system is
customized to the particular configuration during the bootstrap process. This
is actually not too crazy, there are reasons this makes sense.

For one, the whole 'information utility' concept (where Multics admittedly
went down the wrong path, in terms of the future of computers); a single
giant machine (multi-processor, multi-memory bank, multi-I/O controller). The
thing is that any of these could be switched out if it developed a fault, but
then you have to be able to boot that new configuration. (In particular,
Multics wasn't a master-slave multi-processor system, they're all the same;
but only one CPU runs for most of booting, the others are started and added
once the system is running. But the 'bootstrap CPU' might change if the
original bootstrap CPU develops a fault...)

	Noel

             reply	other threads:[~2019-04-16 12:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-16 12:52 Noel Chiappa [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-04-17  5:35 Paul Ruizendaal
2019-04-17 18:26 ` Warner Losh
2019-04-13 18:35 Noel Chiappa
2019-04-11  1:06 Pat Barron
2019-04-11  1:27 ` Charles Anthony
2019-04-11  2:26 ` Erik E. Fair
2019-04-10 18:02 Pat Barron
2019-04-10 18:14 ` Erik E. Fair
2019-04-10 18:28   ` Clem Cole
2019-04-10 19:05     ` Bakul Shah
2019-04-10 22:24       ` Clem Cole
2019-04-10 22:53         ` Warren Toomey
2019-04-11  1:45           ` Greg 'groggy' Lehey
2019-04-10 23:19         ` Bakul Shah
2019-04-11  4:52           ` Fabio Scotoni
2019-04-11 13:48             ` Clem Cole
2019-04-11 14:54               ` Dan Cross
2019-04-11 15:36                 ` Clem Cole
2019-06-26  2:28             ` Peter Jeremy
2019-06-26  7:57               ` Bakul Shah
2019-04-10 16:51 Pat Barron
2019-04-10 17:20 ` Erik E. Fair
2019-04-10 17:57 ` Dan Cross
2019-04-19 22:31 ` Chris Hanson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190416125237.333B918C0BE@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).