From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23142 invoked from network); 18 Aug 2020 00:53:11 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 18 Aug 2020 00:53:11 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id BBC8F9CABE; Tue, 18 Aug 2020 10:53:09 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 69A999CAB3; Tue, 18 Aug 2020 10:52:23 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="t7aekBx1"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 6FD639CAB3; Tue, 18 Aug 2020 10:52:15 +1000 (AEST) Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by minnie.tuhs.org (Postfix) with ESMTPS id 36D0F9C8BB for ; Tue, 18 Aug 2020 10:52:13 +1000 (AEST) Received: by mail-pg1-f195.google.com with SMTP id p37so8941192pgl.3 for ; Mon, 17 Aug 2020 17:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:reply-to:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DF3wNl4NCcM+Qif5/ZuqSWLM5N2nKxY3aEwsHXK6reE=; b=t7aekBx1NMkDbGi9tdWTF/kWraoELo3FzzJsUdH91F+Bz+OweDYC4PReCq5EG4QKrH qRaVevizj8oS4c6gHmBTv2OPtfRSen67tND9cOPGRwLhSkg36waT+JxWWgHvXTxnyene hqYBBReZDzjf77v2A6KBVoUuhxqczXdyDmIf6a5SMHd+ykWunWcWiO8bY92FFZ59RvrD JRFDpssUK3Ufm0vdVysRcUVdsqWc+12fuR0ac/q3nHARJNtH1CG98FRGrMQ4kGqCLjW3 Jkgq00KXdjT+Otqz1AXCd1Q+Rd+PH4cLxAyBepycJ57Fflg+f1ubBr4v8QBdFR+xe5np SWcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:reply-to:subject:to:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=DF3wNl4NCcM+Qif5/ZuqSWLM5N2nKxY3aEwsHXK6reE=; b=oEK+/yRn/MrLXFOYOdNb+wSrQeoEk3s9xNZOwIzFcvOQPA6IkOr/L7ojh0wEUR03xY 3PXO5Hn/z9lnCB+D17/JGXCFs8+cfWUjTk1HoccOgUvMPz77mA+0IJj88RBlsvNEZXD9 K/IUhpclyu+oEXgvlH+T/bRjgfa2LCuxwOcC8t0CjVyDmBALK0OsKgDpWN7JwZo8fuEC I8gfFbvcctUSjv5//EtHqLZML2w9V0TNbG4dAP5CyDncBJHcEbZ1Z5M2lwPTB57r0eVi Goyt5XCDyo+13avI50ezU6LChEHBDLcmNqC288GSFFhNZ24J2OceGo71OaJUGrBORXrv uO1w== X-Gm-Message-State: AOAM530at0mFXmc7foRZM8ILpl0DJBhMjmEpjQLmypKaEHOqxlLbrmY+ FztwUA5TIKqHNMIUyFwxnEayxY56bGXq3A== X-Google-Smtp-Source: ABdhPJyCoYz6BCtVqLcvZQJZiln8zTDEi+MZvlcWHlfzx8vT5/0HYdWy+6Dq9rPjdKbBcJa1k3DSRg== X-Received: by 2002:a62:2704:: with SMTP id n4mr13566778pfn.246.1597711931361; Mon, 17 Aug 2020 17:52:11 -0700 (PDT) Received: from [10.0.0.18] (c-98-210-178-152.hsd1.ca.comcast.net. [98.210.178.152]) by smtp.gmail.com with ESMTPSA id e29sm21575158pfj.92.2020.08.17.17.52.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Aug 2020 17:52:10 -0700 (PDT) To: tuhs@minnie.tuhs.org References: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> From: Rob Gingell Message-ID: Date: Mon, 17 Aug 2020 17:52:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200817192715.22D9518C09E@mercury.lcs.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [TUHS] Memory management in Dennis Ritchie's C Compiler X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: gingell@computer.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 8/17/2020 12:27 PM, Noel Chiappa wrote: > > From: Jim Geist > > > When did mmap(2) come about? > > Pretty sure it's a Berserkleyism. I think it came in with the VM stuff that > DARPA mandated for VAX Unix (for the research project they funded). [What follows verges on being COFF-ish]. mmap() is descended from TENEX's PMAP, which is a simplified descendant of the file/process memory integration provided by Multics. (Other antecedents I leave to more informed genealogists than I.) A Multics process had an address space made up of segments (files) which were paged (vs. swapped). Segments were what programs dealt with, paging was done to manage the physical resources of the system. TENEX simplified everything to pages, address spaces were composed by mapping pages of the address space to files. Programs operated on pages, which were also what the system used to manage memory. Files were described by page tables, address spaces were described by page tables, lots of symmetry around things of size 512 (9 bits) (page size, page table size, page-tables of page tables for long files). File size and file system system capacities were announced in pages. Very harmonious, but uniquely so. Multics was most definitely not portable due to its unique hardware constraints (Intel's 432 being an exception). TENEX only required paging support but was not portable from PDP-10s which were not keeping up with the world's movement to computers that were increasingly 4-bits shy of a word (i.e., not 36 bits). Many more considerations apply but to keep it only verging on COFF-ish will stop there -- going deeper would be best done in person with tankards of ale. TENEX systems were ARPA's workhorse systems in the 1970s, supporting numerous research programs and sites. The file/process memory integration was a valued capability among the community (though, honestly, it was one of these things everyone said should exist though few actually used directly). Even though DEC provided commercial support by adopting TENEX as TOPS-20 and selling 1000s of them (vs. the 10s of them made via BBN + PARC's MAXC), as the 70's progressed it was apparent that things were going to shift elsewhere. DEC was hesitant about further 36-bit development and UNIX's arrival provided an intellectual migration path for the community that commercial alternatives didn't. If only UNIX could just accumulate some of the capabilities expected in the ARPA world, like file/process memory integration (ironically, one of the Multics complexities from which UNIX had departed.) mmap() is a simplified, portable form of PMAP. It was written into the specifications for ARPA via Bill Joy as Larry McVoy and Noel Chiappa noted. It existed only as a specification for quite a while. First implementations were as a device-driver level function for things like frame-buffers for use by window systems and perhaps for other devices I'm not remembering at the moment. The general file/process memory integration aspect didn't happen prior to SunOS 4.0 though I seem to recall some special-case subsets being tried by other UNIX implementations and also more generally with Mach, I believe. The gestalt of file/process memory integration in 4.0 was very TENEX-like in how it was used in fork()/exec()/brk()/shared libraries. 4.0 differed from TENEX in being portable, launched on heterogeneous hardware (VAX, 68010 (Sun-2's), 68020 (Sun-3's), 386 (386i), SPARC (Sun-4) all except the VAX being actively supported Sun products at the time), and a general-networking view of how coherency should work (vs. a clustered-network such as TOPS-20's CFS.) (As a hysterical note, every release of (BSD-based) SunOS through 4.0 was always ported to the VAX as a portability check. It also provied us utility as a convenient way to quickly check for "but it works on the VAX" problems with new things gotten from UCB. Prior to 4.0, given that the BSD-based implementation basically tried to mimic a VAX internally, that wasn't too bad. But the VAXectomy that occurred in 4.0 made that much more daunting, and so the 4.0 VAX port was a pretty half-hearted attempt and the last new task for the 11/750 that faded deeper and deeper into the back of the lab over time.)