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 --]
next prev parent 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).