From: Clem Cole <clemc@ccc.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] 2.9bsd with networking on 18-bit possible?
Date: Tue, 11 Dec 2018 11:26:41 -0500 [thread overview]
Message-ID: <CAC20D2NxzMvta6vP6pqsghHKpSUqE3f0sCWCgYArNqtVpaeRwA@mail.gmail.com> (raw)
In-Reply-To: <20181211161631.0053818C089@mercury.lcs.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 3304 bytes --]
IIRC is how UNET worked for V7.
FWIW: UNE T was the original product from 3COM and somewhere I have the
package with the Postmark as the 32nd of December - because 3Com had a
requirement to ship by the end of the year to their VCs. At the last
hours, Greg Shaw and Bruce Borden ran into a problem, so it shipped a day
late [they obviously got their money].
Clem
ᐧ
On Tue, Dec 11, 2018 at 11:17 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:
> > From: Clem Cole <clemc@ccc.com>
>
> > 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
>
> Really, the answer is that I need to get off my @ss and put the MIT V6+
> system
> up (I have all the files, just need to get a round tuit).
>
>
> It has TCP/IP, but is it not all crammed into the kernel. And unlike the
> early
> BBN V6, it doesn't do TCP as a single process to which all the other
> client/server processes talk via IPC.
>
> Instead, the only thing in the kernel is inbound demuxing, and minimal
> outbound
> processing. (IIRC, outbound packets are copied into kernel buffers; an
> earlier
> version of the networking interface driver actually did do inbound and
> outbound
> DMA directly from buffers in the user's process, but only one process
> could use
> the network interface at a time.)
>
> The TCP code was a library that was built into the user process which did
> the
> server/client applications. (The servers which supported login, like FTP,
> needed to run as root, like the ordinary login, setuid'ing to the entered
> user-id.) I don't remember if we supported server Telnet, but I think we
> did. So we must have added PTY's of some sort, I'll have to check.
>
> Since the TCP was in the user process, we actually had a couple of
> different
> ones, depending on the application. Dave Clark had done a quick-n-dirty
> TCP on
> the Alto (in BCPL) which was only good for things like user Telnet, not for
> applications that sent a lot of data. We ported that one for the first
> TCP; we
> later did a 'high-speed bulk data' TCP, used for FTP, etc. I don't remember
> which one SMTP used.
>
> The whole thing worked _really_ well. Alas, I don't think anyone else
> picked
> up on it.
>
>
> The kernel code is not that large, it should even run on a /40, without
> overlays (although the number of disk buffers would probably get hit). And
> since the TCP is in user processes, it could all get swapped out, so it
> would
> run OK on machines without that much physical memory.
>
> The issue is going to be that it will need a new network interface driver,
> since I think the only driver ever done for it was for Pronet. And now we
> get
> back to the 'what interfaces are available' question. Doing a DEC driver
> would
> allow use of DEQNA's and DELQA's on QBUS machines, which would be optimal,
> since they are common. And people could bring up Unix with TCP/IP on
> -11/23's.
>
> But we'd have to add ARP (which I would do as a process, with only the
> IP->Ether address mapping table stored in the kernel). I wrote a really
> nice
> ARP for the C Gateway that could easily be used for that.
>
> Noel
>
[-- Attachment #2: Type: text/html, Size: 4557 bytes --]
next prev parent reply other threads:[~2018-12-11 16:27 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 16:16 Noel Chiappa
2018-12-11 16:26 ` Clem Cole [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-12-15 1:54 Paul Ruizendaal
2018-12-12 17:55 Paul Ruizendaal
2018-12-12 14:38 Noel Chiappa
2018-12-12 14:14 Noel Chiappa
2018-12-12 10:29 Paul Ruizendaal
2018-12-11 18:43 Noel Chiappa
2018-12-11 18:51 ` Clem Cole
2018-12-12 1:20 ` Jacob Ritorto
2018-12-11 16:57 Noel Chiappa
2018-12-11 17:01 ` Jon Forrest
2018-12-11 18:03 ` Clem Cole
2018-12-11 4:42 Noel Chiappa
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-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
2018-12-11 17:21 ` Lars Brinkhoff
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=CAC20D2NxzMvta6vP6pqsghHKpSUqE3f0sCWCgYArNqtVpaeRwA@mail.gmail.com \
--to=clemc@ccc.com \
--cc=jnc@mercury.lcs.mit.edu \
--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).