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.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 4f26bf5c for ; Tue, 11 Dec 2018 16:57:24 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9EE67A1F88; Wed, 12 Dec 2018 02:57:23 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id B2786A1F06; Wed, 12 Dec 2018 02:57:10 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 8BD21A1F06; Wed, 12 Dec 2018 02:57:08 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id 385E9A1EFF for ; Wed, 12 Dec 2018 02:57:08 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3A1E618C089; Tue, 11 Dec 2018 11:57:07 -0500 (EST) To: tuhs@minnie.tuhs.org Message-Id: <20181211165707.3A1E618C089@mercury.lcs.mit.edu> Date: Tue, 11 Dec 2018 11:57:07 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) 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: jnc@mercury.lcs.mit.edu Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" PS: > IIRC, outbound packets are copied into kernel buffers IDRC; according to the documentation, outbound packets are DMA'd directly from user memory. I have yet to read the code to verify this. > we must have added PTY's of some sort There is indeed a PTY driver; it has comments from BBN'ers who edited it, so perhaps we got it from BBN. > I don't remember which one SMTP used. The 'simple' TCP. > The whole thing worked _really_ well. Alas, I don't think anyone else > picked up on it. So I found a long list of people we sent tapes to. Oh well.... > 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). Well, maybe... Here is the output of 'size' on the last Unix image for that machine: 40560+3098+44594 It was a /45, so split I/D (no overlays, though). How much could be trimmed out of that, I'm not sure. Noel