The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: segaloco via TUHS <tuhs@tuhs.org>
To: Rob Pike <robpike@gmail.com>
Cc: tuhs@tuhs.org
Subject: [TUHS] Re: UNIX on (not quite bare) System/370
Date: Mon, 19 Dec 2022 22:15:29 +0000	[thread overview]
Message-ID: <N7OY44B9opZ4dPSe_0Qqq2Xo-Y8f4JUFFsSUuj2P0ytguvneHxqTwViqi-15_STEUU650pt2LKKbVwfEbDQuFzh3p5x6ZzQ99PZQ7KV36IQ=@protonmail.com> (raw)
In-Reply-To: <CAKzdPgzCaQcAoMrLUNwWDE7-324655ytSNfcRedWJ8hjkkPnuA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 11453 bytes --]

If it helps any, the init discrepancies are one of the hints at part of the System III/3.0 lineage. System III has an init much closer in flavor to CB init than the research init (inittab, runlevels).

There are notable differences too, the inittab is in a slightly different format and the runlevels are simply 1-9, no s/S alias for single user mode afaik. 4.1 appears to be the first release to have split a_man and u_man, and I only managed to track down a user manual, so can't compare the init and getty pages, but the inittab entry matches System III, meaning that CB init as we know it didn't make it in until 5.0. In any case, a diff on the III and V versions is pretty stark, leading me to believe if CB init was inspired by this, it was in design only, but possibly a fresh codebase? So hard to tell.

Where this leaves a quandary is where did this init in System III come from? Not a System/370 matter but if anyone knows I'd love to hear you out.

Another matter I've been keeping tabs on in my recent study is the presence of SCCS tags on things. Most System V code has SCCS tags, but only select bits of System III seem to have them. Where they do exist, often times they're either carried through to the System V file verbatim or​ there's some monkeying with the numbers I can't quite explain but I have some hunches. In any case, many of the files unmodified between III and V are listed as SCCS version 1.1 in V. I'm not sure there what the significance of the version numbers was, and in analyzing several versions, i haven't been able to identify a singular pattern. One pattern I did notice sporadically was when comparing SVR1 Release 1 (PDP-11) and SVR1 Release 2 (M68K), all of these SCCS identifiers I checked roll from whatever 1.x they were in the former to 2.1 in the latter, presumably the major number being the System V release and minor being revisions since that was tagged? All speculation though.

In any case, Clem is totally right that nothing is that linear, I was just pulling some references from some documents I have on hand to fill in some of the available context. At the root of it all though there is u370 in the PDP-11 codebase for SVR0/1 (never know which to apply...). So at least by 1982 there was definitely System/370 stuff floating around far enough up the chain to be integrated. Where those actual lines of code came from, can't entirely say, although I have a document I'm scanning tonight that miiiight shed some more light. Appendix I of the System Release Description document for System V is a 62 page list of all the modification requests presumably between 3.0 and 5.0. It's a table with header "NR AREA SUMMARY MR" where NR is just an increasing number, AREA is a rough idea of where it's at (some have program names, some have text like "3.0 manual", SUMMARY is basically a commit message, and then MR is two letters (location/team?), two numbers (year?), a dash, then 5 numbers (issue number?). There are plenty of u370 references throughout, for instance

775 graphics union adrbits in file xytekl.c must be inverted for unix 370 bl81-21610
786 grep an #ifdef should be around u370 code bl81-28302

There are others, just did a quick visual scan for some examples. I've got the entire rest of the document scanned already, just need to get Appendix I and upload it. I think this'll be very informative of what was going on in that timeframe. Unfortunately the order is not chronological as far as I can tell, so it'll take OCR'ing this and then sorting on the MR column to get something like that out of it. I also don't know if the MR number is representative of when something was fixed or reported. Given MR is Modification Request, my assumption is any chronological data is predicated on the report date, not fix date.

Anywho I'll hopefully have that and the other PDFs from that volume somewhere folks can get to them by this evening. Decided to ramp up getting this thing scanned since it'll also contribute to what is pretty much turning into a UNIX 4.x restoration for me. Anywho, hopefully this thing turns up some timelines. More to come!

- Matt G.

------- Original Message -------
On Monday, December 19th, 2022 at 1:19 PM, Rob Pike <robpike@gmail.com> wrote:

> Quite a bit of this feels not exactly wrong, but not quite right. (And his name is John Reiser, not Reisner.) Steve Johnson didn't go to work in development until the mid 1980s, for example, long after these bloodlines as you call them were laid down.
>
> Do we know that PWB became USG? That doesn't feel right to me, although it might well be true, I wasn't there. I think of it as mostly staying in Whippany, not going to Summit. Also your prose would imply USG never got to V7 level, which is certainly not true. Columbus's major contribution, as we saw it from Research, was the world's second most complex init. All these variants lobbied to have Research adopt things, as such approval was seen as a badge of honor. Honestly, though, it was all pretty toxic.
>
> Reiser and London's Unix, which I greatly admired, died on the vine for a variety of political reasons, as well as because it had slightly different semantics in some important cases, and because of a broad antipathy to virtual memory across the company due to various people having used VM on inadequate hardware, and of course then there was Multics. Sandy Fraser was very nervous about Research adopting the BSD kernel because of his experience with Atlas. But let it be said: Reiser's VM system was seriously impressive, cleanly integrated, structurally central, and wonderfully fast. And Sandy relented but the general warmth of 1127 towards Berkeley led to Research adopting Berkeley Unix as its VAX VM platform, despite some, including myself, feeling that was the inferior choice.
>
> -rob
>
> On Tue, Dec 20, 2022 at 8:03 AM Clem Cole <clemc@ccc.com> wrote:
>
>> On Mon, Dec 19, 2022 at 1:54 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>>
>>> All I can comment is there are a number of #ifdef u370 sections added to System V. Happened somewhere between 3.0 and 5.0, likely UNIX/TS. This is my understanding of Bell-adjacent platform work:
>>>
>>> PDP-7 - Research, 1969
>>> PDP-11 - Research, 1970
>>> Interdata 8/32 - Research, 1977
>>> VAX - Research, 1979 (or did USG do 32V, it's sitting in my USG folder...)
>>> 3B20 - UNIX/TS 4.x, 1981
>>> System/370 - UNIX/TS?, 198x
>>> 3B5 - Release 5.0, 1982
>>> M68000 - System V, 1983
>>> Z8000 - System V, 1983
>>
>> Sadly, do I wish it was this linear as you present ;-) Simply - it was not.
>>
>> Just like the folks outside of the Bell System, inside, there were several forks, many of which have been discussed here.
>>
>> Research was its own bloodline. Ken/Dennis et al.. This, of course, was what seeded much of the external work at the Universities with the BSD bloodline as a direct result. There was a good bit of porting work done there, such as the work on the Interdata, IBM S/360, and Honeywell, but most of that work tended to leave the labs in an indirect form.
>>
>> PWB 1.0/2.0 started a different thread - Glaser, Mashey, et al... as a fork of Research Sixth Edition. After many twists and turns, that bloodline would become the Unix Support Group (a.k.a. USG) in Summit (Steve Johnson - a.k.a. yaccman - was a manager in Summit and has offered some enlightenment on this list over the years). As we have often discussed here, the TS line is hugely impure. There is a great question of what was TS and what was not. What was the name and what was actual technology? It's clear it started based on AT&T politics of the mid-late 70s, but as things changed at AT&T and their own internal Unix wars - names and technologies shave been blurred and some of the details were lost to time. We know that the PWB thread (and >>name<< ) would >>eventually<< become the many flavors of Sys V and it was the 'official' line that AT&T started to market -- at first to the Operating Companies and later more widespread commercially. What was PWB and what was TS is not completely clear? (I think Werner may have done so of the best sleuthing here and has reported his learnings in the past).
>>
>> Part of the issues we have as historians was because threads and those twists and turns started before the breakup and were controlled by rules of the 1956 consent decree (TS and PWB itself are examples) and other things happened afterward as Charlie Brown (AT&T CEO) wanted to make a run at being in the computer business. Pre breakup, the AT&T >>commercial<< work was targeted for the Operating Companys. Each group often did different things to deal with specific projects that were being targeted to solve problems that the OCs had.
>>
>> As was pointed out before, the switching folks in Indian Hill not only needed to build things like SW for the ESS#5 (the 370/TSS-based stuff mentioned yesterday helped to support that project) but they were also working on a very slick single system image Unix system [Tom Bishop at friends] that ran on the 3B duplex and some other HW - the /400 IIRC] (FWIW: Tom used to be findable - I've tried to get him on this list a few times). But you will see some #ifdefs in various codes that ended back up in Summit that really are from that work. That said, if I understand things that have been suggested here, officially the Duplex system used an OS that Indian Hill created but was >>seeded<< from Summit, but not the Summit released directly [i.e., IH acted the same way as DEC, Sun, IBM, etc might have].
>>
>> Holmdel ( Reisner et al.) had several projects. The best we3 can tell, is that bloodline seems to have died off due to some internal AT&T politics and reorgs, although a number of things from it seem to have shown up in other bloodlines and different people brought some of the ideas. For instance, while it's not directly there, SVR3's memory system >>seems<< to have had some Reisner's influence. Again we don't have direct evidence other than different people's recollections and some comments people here and elsewhere have found in different sources.
>>
>> Columbus ( Dale's team ) did a great deal of work in several areas. Some of it has been recovered, but not all. Mary Ann, is a one-time member of that team and often comments and fills in some of the history here. FWIW: The PWB 3.0, a.k.a. System III release, got a bunch of the technology from CBUNIX (again discussed at length here over the years) - shared mem, semaphore, ipc, etc.
>>
>> These are just a few and I apologize to anyone that was not mentioned. I offered some highlights to make my point.
>>
>> If you are newer to the list, I respectfully suggest that instead of restarting some of this discussion, please go back into the old Mail archives and you will see a great deal of detail.
>>
>> The most important point I will leave you with is that the different UNIX flavors influenced each other - inside and outside the Bell System. As Larry points out, politics often had a more substantial influence on what 'won' than the 'goodness' of the technology itself in many cases. But the path from the root to any of the leaves includes a great deal of cross-fertilization. It seems to me to be a bit disingenuous to offer a linear statement from one of the bloodlines and infer that was how it all worked, just because some #ifdefs have been found in a few places in some of the different pieces of code, be kernel portions or user space.
>> ᐧ
>> ᐧ

[-- Attachment #2: Type: text/html, Size: 17994 bytes --]

  reply	other threads:[~2022-12-19 22:16 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-19 17:38 [TUHS] " Phil Budne
2022-12-19 18:53 ` [TUHS] " segaloco via TUHS
2022-12-19 21:01   ` Clem Cole
2022-12-19 21:19     ` Rob Pike
2022-12-19 22:15       ` segaloco via TUHS [this message]
2022-12-20  0:02         ` Brad Spencer
2022-12-20  1:04           ` Adam Thornton
2022-12-20  2:35             ` segaloco via TUHS
2022-12-20 14:25           ` Andrew Hume
2022-12-19 23:02       ` Clem Cole
2022-12-20  1:20         ` Larry Stewart
2022-12-20  1:33           ` Larry McVoy
2022-12-20  1:57             ` George Michaelson
2022-12-20  2:06               ` Dan Cross
2022-12-20 15:04                 ` Chet Ramey
2022-12-20  2:12               ` Adam Thornton
2022-12-20 15:29                 ` Andy Kosela
2022-12-20 15:35                   ` Adam Thornton
2022-12-21  2:43                     ` Luther Johnson
2022-12-20 23:18                 ` David Arnold
2022-12-20  2:52       ` Bakul Shah
2022-12-20  3:09         ` Larry McVoy
2022-12-20  3:27           ` Bakul Shah
2022-12-20  3:48           ` Warner Losh
2022-12-20  4:21           ` Jonathan Gray
2022-12-19 21:36 ` Marc Donner
2022-12-19 22:52   ` Charles H Sauer (he/him)
     [not found]   ` <01428a75-3507-7b8a-fd35-cef74c8c0bd2@ucsb.edu>
2022-12-20  1:49     ` [TUHS] Re: pre-1991 USENIX proceedings Marc Donner
2022-12-20  3:11 ` [TUHS] Re: UNIX on (not quite bare) System/370 Warner Losh
2022-12-20  8:56 ` arnold
2022-12-20  9:31   ` segaloco via TUHS
2022-12-20  9:39     ` arnold
2022-12-20  9:55       ` Jonathan Gray
2022-12-20 14:27     ` Clem Cole
2022-12-23  1:53       ` Rob Gingell
2022-12-22 19:00 ` Andrew Hume
2022-12-20 22:25 Noel Chiappa
2022-12-20 23:18 ` Bakul Shah
2022-12-22 17:26 Noel Chiappa
2022-12-22 17:33 ` Dan Cross
2022-12-22 20:25 ` Warner Losh
2022-12-22 23:06   ` Warner Losh

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='N7OY44B9opZ4dPSe_0Qqq2Xo-Y8f4JUFFsSUuj2P0ytguvneHxqTwViqi-15_STEUU650pt2LKKbVwfEbDQuFzh3p5x6ZzQ99PZQ7KV36IQ=@protonmail.com' \
    --to=tuhs@tuhs.org \
    --cc=robpike@gmail.com \
    --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).