The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: segaloco via TUHS <tuhs@tuhs.org>
To: Warner Losh <imp@bsdimp.com>
Cc: Jonathan Gray <jsg@jsg.id.au>,
	The Eunuchs Hysterical Society <tuhs@tuhs.org>,
	Paul Ruizendaal <pnr@planet.nl>
Subject: [TUHS] SysIII and SysV Feature Lineage (was: Documents for UNIX Collections)
Date: Fri, 12 Aug 2022 18:52:41 +0000	[thread overview]
Message-ID: <odXBUns0z_d8bbQRu7BWS6RFpji2HOj-NObpQjSdIHQ-nEyOLD1h9MzB8RNyx1onJHLg92Eez_hxi95pg3kVoaaBVZ1CRFGFiBl5QbjVDJA=@protonmail.com> (raw)

Thread fork as we're drifting from documentation research specifically.

One matter that keeps coming to mind for me is the formal history of the runlevel-based init system.  It isn't in Research obviously, nor was it in PWB.  The first time it shows up in the wild is System III, but this version is slightly different than what was in CB-UNIX at the time, which is what eventually wound up in System V.

The pressing question is whether the version in System III represents an earlier borrowing from CB or if perhaps the runlevel init started in USG, got bumped over to CB and improved, then that improved version came back to supported UNIX in 5.0.

As for the notable differences:

SysIII init allows for runlevels 1-9.  It will call /etc/rc with the current state, the prior state, and the number of times the current state has been entered.  If the script is called for instance due to a powerfailure, then the current state is passed suffixed with an 'x'.  The inittab entries are in a different format:

    state:id:flags:process

Where state is the runlevel, id is a two-character identifier, flags can be either 'c' (like respawn) or 'o' (like off I think).  No flag then indicates to run once.  Flags 't' or 'k' will terminate or kill a process before it is started again if a given runlevel is entered and it is already running.


This of course is in contrast to SysV init which instead offers runlevels 0-6 as well as a, b, and c.  Init itself can be called with runlevels S|s or Q|q additionally and these act as calls to enter single user mode or rerun the current init state if I'm understanding correctly.  Neither S nor Q options appear to be valid for the inittab runlevel.  Init tab entries here are:

    id:rstate:action:process

Where id and rstate are essentially just the same fields from SysIII swapped.  Action replaces the flags field with the more well known respawn, wait, once, initdefault, etc. behaviors.


All in all, different enough that inittabs between the two wouldn't be compatible.  SysV also includes the telinit command which appears to be able to handle those a, b, and c runlevels.

Anywho, that's my understanding of the init changes, with the pertinent question remaining whether the SysIII-style init ultimately started from the same place as SysV, or if the general design idea was there between USG and CB, and they got to a similar answer from different directions.  Colon-delimited /etc files aren't uncommon, so while unlikely, it could be entirely possible the two inittab formats arose relatively independently, but the truth remains obscure in my mind at least.  I don't really blame Research for not picking up this init system, it seems like there were a few parallel streams of development around the turn of the 80s, and the easier answer was probably to just stay the course.  I seem to recall reading in a thread somewhere Rob Pike discussing the resistance in the Research group regarding sucking up each and every little feature USG tried to promulgate as standard, and this init system got specific mention.

- Matt G.

                 reply	other threads:[~2022-08-12 18:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='odXBUns0z_d8bbQRu7BWS6RFpji2HOj-NObpQjSdIHQ-nEyOLD1h9MzB8RNyx1onJHLg92Eez_hxi95pg3kVoaaBVZ1CRFGFiBl5QbjVDJA=@protonmail.com' \
    --to=tuhs@tuhs.org \
    --cc=imp@bsdimp.com \
    --cc=jsg@jsg.id.au \
    --cc=pnr@planet.nl \
    --cc=segaloco@protonmail.com \
    /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).