From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id C5BFB228ED for ; Wed, 19 Jun 2024 18:17:32 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 20DFC436D7; Thu, 20 Jun 2024 02:17:28 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id C9A8642A20 for ; Thu, 20 Jun 2024 02:17:21 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B301E18C088; Wed, 19 Jun 2024 12:17:20 -0400 (EDT) To: tuhs@tuhs.org Message-Id: <20240619161720.B301E18C088@mercury.lcs.mit.edu> Date: Wed, 19 Jun 2024 12:17:20 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Message-ID-Hash: 7ZBHBWCHHAHWXICFYHL3XGTLP5RJH4BB X-Message-ID-Hash: 7ZBHBWCHHAHWXICFYHL3XGTLP5RJH4BB X-MailFrom: jnc@mercury.lcs.mit.edu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: jnc@mercury.lcs.mit.edu X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: [COFF] Re: Supervisor mode on ye olde PDP-11 List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > From: Warner Losh > 2.11BSD used a mode between kernel and user for the TCP stack to get > more effective address space... Is there a document for 2.11 which explains in detail why they did that? I suspect it's actually a little more complicated than just "more address space". The thing is that PDP-11 Unix had been using overlays in the kernel for quite a while to provide more address space. I forget where they first came in (I suspect there were a number of local hacks, before everyone started using the BSD approach), but by 2.9 BSD they were a standard part of the system. (See: https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/sys/conf/Ovmakefile for some clues about how this works. There is unfortunately no documentation that I know of which explains clearly how it works; if anyone knows of any, can you please let me know? Otherwise you'll have to read the sources.) I can think of two possible reasons they started using supervisor mode: i) There were a limited number of the 2.9-type overlays, and they were not large; trying to support all the networking code with the existing overlay system may have been too hard. ii) I think this one is unlikely, but I'll list it as a possibility. Switching overlays took a certain amount of overhead (since mapping registers had to be re-loaded); if all the networking code ran in supervisor mode, the supervisor mode mapping registers could be loaded with the right thing and just left. Noel