The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Lars Brinkhoff <lars@nocrew.org>
Cc: TUHS main list <tuhs@minnie.tuhs.org>,
	Grant Taylor <gtaylor@tnetconsulting.net>
Subject: Re: [TUHS] 2.9bsd with networking on 18-bit possible?
Date: Tue, 11 Dec 2018 10:28:32 -0500	[thread overview]
Message-ID: <CAC20D2N0sfVm-WNHu5yzE3W7sDS+WAQBshkk67aFC_vO+h31sQ@mail.gmail.com> (raw)
In-Reply-To: <7wk1kg34u0.fsf@junk.nocrew.org>

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

Having had an extremely small part to play in 2.x story (some of my code is
in there), I can offer a little of the history which hopefully you can
glean some wisdom:

re: NCP

   1. The NCP code from Illinois, Rand *et al* - talked to the BBN-1822
   interface.   To my knowledge, no other networking interface was connected
   to that code base.
      - 1822 interface board are not be found
      - what would you connect the other end too?
      - Which means that you need to write an NCP driver for some other
      networking HW you can find for the Unibus
   2. The only PDP-11 @ UCB that might have ever run the NCP code was Ing70
   and that was long before 2BSD was released (much less 2.X)
      - As Noel pointed out, there is no NCP code in the 2.9 BSD
      distribution

re: BSD 2.x & BSD 3.0 - 4.1

   1. BSD 2.0 was the Seventh Edition changes from UCB for the PDP-11
   (primarily what was running on the Cory Hall System)
   2. BSD 3.0 was the first Vax release for "Ernie" in Evans.     For all
   intents this is 2.0 + changes to the Kernel to allow V7 to run on a 780
   with paging turned on [I don't remember if csh is default shell for root,
   it might be -> a user used to the way the 7th edition worked if presented
   with BSD 3.0 will find 'finger ROM/muscle memory' compatibility].
   3. BSD 4.1 was the widely released Vax distribution where Research
   Editions and BSD began to diverge.   This was the system that convinced
   ARPA to make UNIX the supported OS for the next generation being VMS [which
   was being pushed by Stanford].
   4. Anything in the 2.X line post the original 2BSD tape was a group of
   mostly undergrads trying to move features from Ernie back to the Cory Hall
   system.   These changes were then duplicated around campus (Math and Stat
   Depts as an example) who had purchased PDP-11s.  The first big change was
   adding overlays for applications so larger address user programs like vi
   could keep running.   But you tended to need at least sperate I/D (i.e. the
   17th address bit as I like to call it).
   5. Once the kernel overlay code (which I think was about 2.7) was added,
   it was pretty amazing how much the PDP-11 team did getting many of the
   later Vax kernel features supported, such a FFS, MIT's Job Control for the
   csh, new signals and even networking on some systems with 'enough' main
   memory [i.e. the 22BIT ones].

 re: IP and BSD

   1. UCBVAX (running BSD 4.1) was spliced to the Internet via IP/TCP using
   the BBN 1.0 IP/TCP release for the Vax by Eric Cooper
   2. BSD 4.1a thru 4.2 were different versions of Vax work from the new
   CSRG team with new features for the Arpa community; including the creation
   of sockets and resplicing the BBN stack back the new kernel.

So the issue you will run into is that to get all of the features that were
crammed into BSD 2.X from the Vax, you need 'enough' memory to keep the
overlays loaded.  I do not believe the Kernel can swap itself out.

Besides the kernel (i-space) code itself, space for I/O buffers becomes a
huge issue (it always was before you added networking on the Research
systems).   To compound the issue, the networking code has its own memory
scheme call 'mbufs' which came from the original BBN code [Rob wrote it to
be portable to multiple OS's not just UNIX - the BBN distribution works on
things like the HP/3000 also].   Space for all the buffers is going to be
your problem.   The less kernel code you have resident, the more room you
have for applications code and I/O buffers.

This is why I suggested that if you really want telnet and ftp to the
PDP-11, you might be better off moving the networking stack out of the
kernel and put a serial line (or even a DR-11B with a simple transfer
protocol) via an Arduino or the like.
ᐧ

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

  reply	other threads:[~2018-12-11 15:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 22:05 Jacob Ritorto
2018-12-11  1:21 ` Clem cole
2018-12-11  1:55   ` Grant Taylor via TUHS
2018-12-11  7:22     ` Lars Brinkhoff
2018-12-11 15:28       ` Clem Cole [this message]
2018-12-11 17:21         ` Lars Brinkhoff
2018-12-11  2:11 Noel Chiappa
2018-12-11  2:36 ` Grant Taylor via TUHS
2018-12-11  3:28   ` Warner Losh
2018-12-11  4:42 Noel Chiappa
2018-12-11 16:16 Noel Chiappa
2018-12-11 16:26 ` Clem Cole
2018-12-11 16:57 Noel Chiappa
2018-12-11 17:01 ` Jon Forrest
2018-12-11 18:03 ` Clem Cole
2018-12-11 18:43 Noel Chiappa
2018-12-11 18:51 ` Clem Cole
2018-12-12  1:20   ` Jacob Ritorto
2018-12-12 10:29 Paul Ruizendaal
2018-12-12 14:14 Noel Chiappa
2018-12-12 14:38 Noel Chiappa
2018-12-12 17:55 Paul Ruizendaal
2018-12-15  1:54 Paul Ruizendaal

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=CAC20D2N0sfVm-WNHu5yzE3W7sDS+WAQBshkk67aFC_vO+h31sQ@mail.gmail.com \
    --to=clemc@ccc.com \
    --cc=gtaylor@tnetconsulting.net \
    --cc=lars@nocrew.org \
    --cc=tuhs@minnie.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).