From: Warner Losh <imp@bsdimp.com>
To: Jonathan Gray <jsg@jsg.id.au>
Cc: Paul Ruizendaal <pnr@planet.nl>,
The Eunuchs Hysterical Society <tuhs@tuhs.org>,
segaloco <segaloco@protonmail.com>
Subject: [TUHS] Re: A few comments on porting the Bourne shell
Date: Sat, 31 Dec 2022 22:25:49 -0700 [thread overview]
Message-ID: <CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com> (raw)
In-Reply-To: <Y7EOWnbRLOBecVD9@largo.jsg.id.au>
[-- Attachment #1: Type: text/plain, Size: 6434 bytes --]
On Sat, Dec 31, 2022, 9:38 PM Jonathan Gray <jsg@jsg.id.au> wrote:
> On Sat, Dec 31, 2022 at 07:55:28PM -0700, Warner Losh wrote:
> > On Sat, Dec 31, 2022 at 5:55 AM Paul Ruizendaal <pnr@planet.nl> wrote:
> >
> > > The "assembly code in the Bourne shell" comment is in the same
> > > London/Reiser paper. The full quote is:
> > >
> > > "The (Bourne) shell is the standard user command interpreter. It
> required
> > > by far the largest conversion effort of any supposedly portable
> program,
> > > for the simple reason that it is not portable. Critical portions are
> coded
> > > in assembly language and had to be painstakingly rewritten. The shell
> uses
> > > its own sbrk which is functionally different from the standard routine
> in
> > > libc. The shell wants the routine which fields a signal to be passed a
> > > parameter giving the number of the signal being caught; signal was
> also a
> > > private rou- tine. This was handled by having the operating system
> provide
> > > the parameter in the first place, doing away with the private code for
> > > signal. The code in fixargs (for constructing the argument list to an
> exec
> > > system call) had to be diddled."
> > >
> > > The files in the V7 tree on the Tuhs website are dated January 1979,
> so it
> > > would seem that the fixes for 32V were immediately taken back to
> Research.
> > > As you point out, this means that the comments above do not refer to
> the
> > > well known source code, but to a predecessor of that (which I don’t
> think
> > > survived).
> > >
> >
> > We have ample evidence that V7 was really something more akin to a
> rolling
> > release. Let me explain: We know from the leaked '50 changes' tape that
> > many of the features were set earlier rather than later. This leaked in
> > 1978 (if my notes are right), but I found references to it from as early
> as
> > November 1976 in
> > http://www.toad.com/early-usenix-newsletters/197611-unix-news-n11.pdf.
> This
> > was 18 months after V6 was released, but over 2 years before V7 was
> > released. In addition, we know from the AUUS newsletters in the archive
> > document that the V7 release process process took a while to get through
> > AT&T's legal department (IIRC a year, but I've not gone back to the AUUS
> > newsletters to refresh my recollection). A big push of V7 was to make it
> > portable as well (with AT&T doing an Interdata 8/32 port themselves, as
> > well as at least looking at the Wollongong Interdata 7/32 port and the
> > Harvard VM/370 port). In talking to Kirk and others that have been around
> > from approximately that time, 32V was widely viewed as V7 for Vaxen. We
> can
> > see evidence in the surviving 32V files of evolution from the
> 'PDP-11-like
> > swapping to a more sophisticated paging algorithm' since we have the
> > slowsys directory. It's my contention, as someone that coded in the era
> > before good source code control, that it's evidence that somebody got it
> > working, then renamed/copied it to slowsys while they got paging working
> so
> > they could build either kernel for A/B testing. Kirk has also told me
> that
> > the 32V port was started well in advance of V7's release to be both a
> > useful product inside of Bell Labs (since Vaxen were starting to appear)
> as
> > well as to prove that V7 was portable enough. I'll be the first to admit
> > this is at best conjecture that matches available facts, artifacts and
> old
> > timers recollections (sorry Kirk), but that we have no direct evidence
> for.
> > It also allowed the 3BSD efforts to get going before the official V7
> > release due to the close ties between Bell Labs and Berkeley and the
> DARPA
> > project around Unix.
>
> "So DEC came to us at Holmdel. We were clearly the second string.
> Tom London and John Reiser were interested and so was Ken Swanson, and
> we got the VAX in early '78. I didn't do any of the technical work. In
> fact, I devoted a lot of energy and time to getting the management to
> let us do it. It wasn't research, you see. However, they let us take
> the time. And in about three months my small group ported Version 7 to
> the VAX. We got the machine in January, they had it running in April,
> and by August it really worked.
> ...
> So, with the blessings of BTL Area 11 management, we sent 32V to
> Berkeley. It was in October or November, 1978"
>
> Charlie Roberts in Salus QCU
>
> "The operating system is Research version 7 as of April 15, 1978.
> ..
> Work on the C compiler began in mid-December 1977. The hardware arrived
> on March 3. We held a party on May 19 to celebrate successful multiuser
> operation of the system."
>
> London and Reiser
> A UNIX Operating System for the DEC VAX-11/780 Computer
> https://www.bell-labs.com/usr/dmr/www/otherports/32v.html
>
> >
> > I believe that we can conclude that the original 'hard to port' Bourne
> > shell was produced around the time of the 50 changes tape, give or take.
> > And that all the unix porting efforts that pre-dated the V7 release
> rolled
> > what appeared in 32V into V7 to reduce the amount of pdp-11 assembler.
> And
> > those efforts are what we read about in the paper.
>
> "The Bourne shell work started either in early 1976, or maybe
> late 1975. The first version was VERY different"
>
> John Mashey in net.unix-wizards, 18 Mar 86
> https://groups.google.com/g/alt.folklore.computers/c/xW3ZgEnFoFs
> tuhs/Documentation/AUUGN/AUUGN-V06.6.pdf pg 39
>
> "In 1976, Steve Bourne, who had recently joined 1127, wrote a new shell"
> Kernighan, UNIX A History and a Memoir, 5.1 pg 88
>
> Bourne's AsiaBSDCon 2016 talk also lists 1976
> and goes on to discuss sbrk() use causing problems with ports
> https://youtu.be/7tQ2ftt3LO8?t=715
And at 5:18 he says he had a vax lab with three vaxen and the Lab's vax
port didn't have virtual memory. Bill Joy with 3BSD which had virtual
memory. They installed it on the vaxen because they were hitting physical
memory limits for some of their programs....
This suggests that the 32V in the TUHS archive is a later one than this
early port. 3BSD is listed as being released end of 1979...
Still begs the question of when 32v started paging. :)
But the time lines match up for the 32v effort to be fed back into the
research code base...
Warner
>
>
[-- Attachment #2: Type: text/html, Size: 8139 bytes --]
next prev parent reply other threads:[~2023-01-01 5:27 UTC|newest]
Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-30 18:25 [TUHS] " Paul Ruizendaal
2022-12-30 19:51 ` [TUHS] " Chet Ramey
2022-12-30 20:02 ` Larry McVoy
2022-12-30 20:31 ` Adam Thornton
2022-12-30 20:49 ` Chet Ramey
2022-12-30 20:42 ` Sven Mascheck
2022-12-30 20:48 ` Jon Steinhart
2022-12-30 20:51 ` Sven Mascheck
2022-12-31 11:40 ` Ralph Corderoy
2022-12-31 18:49 ` Jon Steinhart
2022-12-31 19:24 ` Clem Cole
2023-01-03 16:32 ` Chet Ramey
2023-01-01 1:51 ` Ron Natalie
2023-01-02 20:03 ` [TUHS] Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) Joseph Holsten
2023-01-02 20:33 ` [TUHS] Re: Command Line Editing in the Terminal Driver Lars Brinkhoff
2023-01-11 2:51 ` Chris Hanson
2023-01-11 3:53 ` Greg 'groggy' Lehey
2023-01-02 21:08 ` [TUHS] Re: Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) Rob Pike
2023-01-03 16:53 ` Marshall Conover
2023-01-04 9:18 ` Joseph Holsten
2023-01-11 2:56 ` Chris Hanson
2022-12-30 20:47 ` [TUHS] Re: A few comments on porting the Bourne shell Chet Ramey
2022-12-31 0:08 ` Luther Johnson
2022-12-31 3:59 ` Larry McVoy
2022-12-31 4:12 ` Steve Nickolas
2022-12-31 4:18 ` Bakul Shah
2022-12-31 4:40 ` Larry McVoy
2022-12-31 4:19 ` Marc Donner
2022-12-31 4:23 ` Dave Horsfall
2022-12-31 4:37 ` Clem Cole
2023-01-02 5:10 ` Mary Ann Horton
2023-01-02 16:25 ` Clem Cole
2023-01-02 16:51 ` Larry McVoy
2023-01-02 17:32 ` Adam Thornton
2023-01-02 17:43 ` Larry McVoy
2023-01-02 17:48 ` Luther Johnson
2023-01-02 18:00 ` G. Branden Robinson
2023-01-02 18:05 ` Luther Johnson
2023-01-02 18:12 ` Larry McVoy
2023-01-02 18:16 ` Clem Cole
2023-01-02 19:50 ` Warner Losh
2023-01-02 20:05 ` Adam Thornton
2023-01-02 19:21 ` G. Branden Robinson
2023-01-02 19:34 ` Rich Salz
2023-01-02 20:12 ` Larry McVoy
2023-01-02 20:24 ` G. Branden Robinson
2023-01-02 20:41 ` Larry McVoy
2023-01-02 21:00 ` Dan Cross
2023-01-02 21:06 ` Clem Cole
2023-01-02 21:19 ` Dan Cross
2023-01-02 22:54 ` segaloco via TUHS
2023-01-02 23:58 ` Jon Steinhart
2023-01-04 9:00 ` Joseph Holsten
2023-01-02 22:43 ` Steve Nickolas
2023-01-02 21:08 ` Joseph Holsten
2023-01-02 21:15 ` Adam Thornton
2023-01-02 17:55 ` Adam Thornton
2023-01-02 18:11 ` Clem Cole
2023-01-02 18:36 ` Dan Cross
2023-01-02 18:48 ` Dan Cross
2023-01-02 18:18 ` Larry McVoy
2023-01-04 3:20 ` John Cowan
2023-01-04 3:31 ` Dan Cross
2023-01-04 4:16 ` Bakul Shah
2023-01-04 16:15 ` Dan Cross
2023-01-04 18:28 ` ron minnich
2023-01-04 19:33 ` Chet Ramey
2023-01-04 15:21 ` Ralph Corderoy
2023-01-04 15:54 ` Ron Natalie
2023-01-02 17:55 ` Clem Cole
2023-01-03 17:08 ` Paul Winalski
2023-01-03 19:19 ` Warner Losh
2023-01-03 19:56 ` Luther Johnson
2023-01-03 20:21 ` Dave Horsfall
2023-01-03 21:47 ` Clem Cole
2023-01-03 21:51 ` Clem Cole
2022-12-31 4:41 ` Greg 'groggy' Lehey
2022-12-30 20:20 ` Sven Mascheck
2022-12-30 20:49 ` Ron Natalie
2022-12-30 20:52 ` Rob Pike
2022-12-30 20:53 ` Jon Steinhart
2023-01-01 10:44 ` arnold
2023-01-01 11:28 ` arnold
2023-01-03 16:34 ` Chet Ramey
2023-01-03 15:06 ` Chet Ramey
2022-12-30 19:57 ` segaloco via TUHS
2022-12-31 12:55 ` Paul Ruizendaal
2023-01-01 2:55 ` Warner Losh
2023-01-01 4:38 ` Jonathan Gray
2023-01-01 5:25 ` Warner Losh [this message]
2023-01-01 5:35 ` Dan Cross
2023-01-01 5:52 ` G. Branden Robinson
2023-01-01 6:35 ` Warner Losh
2023-01-01 6:35 ` Rob Pike
2023-01-01 6:27 ` Warner Losh
2023-01-01 14:50 ` Ron Natalie
2023-01-01 7:11 ` Jonathan Gray
2023-01-01 7:21 ` Warner Losh
2023-01-01 10:25 ` Paul Ruizendaal
2022-12-31 13:26 Douglas McIlroy
2022-12-31 22:19 ` Rob Pike
2023-01-03 15:08 Douglas McIlroy
2023-01-03 15:57 ` Alejandro Colomar
2023-01-03 17:19 ` Jon Steinhart
2023-01-05 13:22 ` Tom Ivar Helbekkmo via TUHS
2023-01-05 21:11 ` Rob Pike
2023-01-03 17:26 ` Dan Cross
2023-01-03 18:07 ` Steve Nickolas
2023-01-03 20:19 ` Steffen Nurpmeso
2023-01-03 23:03 ` ron minnich
2023-01-04 1:37 ` Bakul Shah
2023-01-04 1:58 ` Adam Thornton
2023-01-04 15:19 ` Ralph Corderoy
2023-01-04 18:01 ` Bakul Shah
2023-01-04 20:46 ` Alejandro Colomar
2023-01-05 0:06 ` John Cowan
2023-01-05 0:41 ` Adam Thornton
2023-01-04 5:05 ` Theodore Ts'o
2023-01-03 18:19 ` Niklas Karlsson
2023-01-04 1:29 ` Adam Thornton
2023-01-05 1:51 ` Alejandro Colomar
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='CANCZdfr57kJvxgK7HvgVr2YrOC51SG=qEyqn9nzMtsTKLBA0Yw@mail.gmail.com' \
--to=imp@bsdimp.com \
--cc=jsg@jsg.id.au \
--cc=pnr@planet.nl \
--cc=segaloco@protonmail.com \
--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).