From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 64ce674d for ; Tue, 11 Dec 2018 16:27:47 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 68E6FA1F76; Wed, 12 Dec 2018 02:27:46 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AFE01A1F06; Wed, 12 Dec 2018 02:27:22 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 66981A1F06; Wed, 12 Dec 2018 02:27:16 +1000 (AEST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by minnie.tuhs.org (Postfix) with ESMTPS id 7224BA1EFF for ; Wed, 12 Dec 2018 02:27:10 +1000 (AEST) Received: by mail-wm1-f46.google.com with SMTP id y1so2841370wmi.3 for ; Tue, 11 Dec 2018 08:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tLue8EGO7r0dJCWbuC5Km+SYTNrVa4r1QFXDMDXpdII=; b=BOFh55iJDktK7TdDPjeIpS2zr1wFTnrHX/e/SR8qkHdpwKbulFIser2zqDM/x9PIN7 TMewuthogMIxreJHS6njyR9m5su89SvDup+6lg1Osme4pKY5XXY4HTs1tIyN8m9MnLA8 CH5efMNDT0TBufW3nVRbrg31q6XQVPa2XzwE4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tLue8EGO7r0dJCWbuC5Km+SYTNrVa4r1QFXDMDXpdII=; b=qBTw2Olt7ttutlCZwh6KtWAFPgFOcnBqn9WbVCj3NCmi0TKzwEwbpgUnIREh6AnNKA iRvlewxZiKHPp8/7yzvYtwZHXhd04Urs03GEYazoOmdCg55kJ+KrFm+u3ttTQBwqKN0J 3IeiCGZDzlkEGC44tukgNfTSnnaLq6iaMPG2LgnDQimdFjENZrPmrTJLImulIYd5cQ/K EnYiYOkimvCHeMSgu4lG9tdHxvSuOuFhV+7oNlUxAeh8j1LFzOcrzstQPUvLqgeuY+jy l7E4IrMBCJmIb03oovrqiXQgZLk9pjU0m7VuAOx5806gc2W+bkSeG/iNSq3NvY4F/M8x AbRg== X-Gm-Message-State: AA+aEWZxgI7lDVwHrb7n9Uoq4bFTC7xM3xGOzzcrERhdNeL4CR74K+yD Rucv+KLaz32MJ5zxE3Lgsdns/TCWvl1TBiycLxdYzEQ4 X-Google-Smtp-Source: AFSGD/VwVTdsREDhJPGbrRFDuScbA2xlUWRpjD4tun8DRkmGyjFmIN32l1/BFOUiAzwb+BsIDtrD9vAhnRT0uqrSu64= X-Received: by 2002:a1c:aa0f:: with SMTP id t15mr2896182wme.108.1544545627894; Tue, 11 Dec 2018 08:27:07 -0800 (PST) MIME-Version: 1.0 References: <20181211161631.0053818C089@mercury.lcs.mit.edu> In-Reply-To: <20181211161631.0053818C089@mercury.lcs.mit.edu> From: Clem Cole Date: Tue, 11 Dec 2018 11:26:41 -0500 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="0000000000007d87e4057cc18d83" Subject: Re: [TUHS] 2.9bsd with networking on 18-bit possible? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000007d87e4057cc18d83 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =E1=90=A7 On Tue, Dec 11, 2018 at 11:17 AM Noel Chiappa wrote: > > From: Clem Cole > > > This is why I suggested that if you really want telnet and ftp to t= he > > 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 f= or > 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 rememb= er > 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). A= nd > 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 > --0000000000007d87e4057cc18d83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IIRC is how UNET worked for V7.=C2=A0=C2=A0

FWIW:=C2=A0UNE=C2=A0T=C2=A0was 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 t= o their VCs.=C2=A0 =C2=A0At the last hours, Greg Shaw and Bruce Borden ran = into a problem, so it shipped a day late [they obviously got their money].<= /div>

Clem
3D""=E1=90=A7

On Tue, Dec 11, 2018 at 11:17 AM Noel = Chiappa <jnc@mercury.lcs.mit.= edu> wrote:
=C2=A0 =C2=A0 > From: Clem Cole <clemc@ccc.com>

=C2=A0 =C2=A0 > This is why I suggested that if you really want telnet a= nd ftp to the
=C2=A0 =C2=A0 > PDP-11, you might be better off moving the networking st= ack out of the
=C2=A0 =C2=A0 > kernel

Really, the answer is that I need to get off my @ss and put the MIT V6+ sys= tem
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 ea= rly
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 outb= ound
processing. (IIRC, outbound packets are copied into kernel buffers; an earl= ier
version of the networking interface driver actually did do inbound and outb= ound
DMA directly from buffers in the user's process, but only one process c= ould use
the network interface at a time.)

The TCP code was a library that was built into the user process which did t= he
server/client applications. (The servers which supported login, like FTP, needed to run as root, like the ordinary login, setuid'ing to the enter= ed
user-id.) I don't remember if we supported server Telnet, but I think w= e
did. So we must have added PTY's of some sort, I'll have to check.<= br>
Since the TCP was in the user process, we actually had a couple of differen= t
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= 9;t remember
which one SMTP used.

The whole thing worked _really_ well. Alas, I don't think anyone else p= icked
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).=C2= =A0 And
since the TCP is in user processes, it could all get swapped out, so it wou= ld
run OK on machines without that much physical memory.

The issue is going to be that it will need a new network interface driver,<= br> since I think the only driver ever done for it was for Pronet. And now we g= et
back to the 'what interfaces are available' question. Doing a DEC d= river would
allow use of DEQNA's and DELQA's on QBUS machines, which would be o= ptimal,
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<= br> 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.

=C2=A0 =C2=A0 =C2=A0 Noel
--0000000000007d87e4057cc18d83--