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.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FAKE_REPLY_B,MAILING_LIST_MULTI autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 21195 invoked from network); 1 Oct 2021 11:37:33 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2021 11:37:33 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 4DC029CBB3; Fri, 1 Oct 2021 21:37:28 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 51BD69CB95; Fri, 1 Oct 2021 21:36:51 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="0Ryl6k3a"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 634689CB95; Fri, 1 Oct 2021 21:36:45 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.167]) by minnie.tuhs.org (Postfix) with ESMTPS id 381789CB92 for ; Fri, 1 Oct 2021 21:36:40 +1000 (AEST) X-KPN-MessageId: d0d3217c-22ab-11ec-9a2e-005056abbe64 Received: from smtp.kpnmail.nl (unknown [10.31.155.38]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id d0d3217c-22ab-11ec-9a2e-005056abbe64; Fri, 01 Oct 2021 13:36:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:date:message-id:subject:mime-version:content-type:from; bh=xpGJ4mrXwCQVnmM1pleb/1ns4IqZe6WO4mDiN33tcE4=; b=0Ryl6k3adChzXlnkSxVgR94PZu70jfyE+dFIdbGL7p0FlZBbSElVQkSQ3HgiwKRGujP3yTMvyNSZc yhZq8BNtSLt8N3SgTn2xiKTcNmFcqKKko3hdpsTvXRjRxjOPwUblcfzBDtz86ami6xDbz+pu0nqDC7 q4vyH1OYLrcEIqiU= X-KPN-MID: 33|NqbV/C80ktBepP5ANLsn6t2V1ITPuA085mZiy4CTbT+0PBFd+Q/528nOnFDHBzK sa2OyKfb4li5C+Tjthe9/tHa/XKHTzEw+KjB5SRdVmlw= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|XDBSwfodKW34UOBkovO+pb2ai+T1N5sKXx55C1LE8Vbve0YAHQbzyPFpqn++Kre WSz0/4PRH1ZlmzVtw1qL5qA== X-Originating-IP: 80.101.112.122 Received: from mba2.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id d0c50a57-22ab-11ec-94d2-005056abf0db; Fri, 01 Oct 2021 13:36:28 +0200 (CEST) From: Paul Ruizendaal Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Fri, 1 Oct 2021 13:36:27 +0200 To: TUHS main list X-Mailer: Apple Mail (2.3608.120.23.2.4) Subject: Re: [TUHS] mmap origin (was Systematic approach to command-line interfaces) 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Dan wrote: > 3BSD and I think 4.1BSD had vread() and vwrite(), which looked like=20 > regular read() and write() but accessed pages only on demand. I was a=20= > grad student at Berkeley at the time and remember their genesis. Bill=20= > and I were eating lunch from Top Dog on the Etcheverry Hall plaza, and=20= > were talking about memory-mapped I/O. I remember suggesting the actual=20= > names, perhaps as a parallel to vfork(). I had used both TENEX and=20 > Multics, which both had page mapping. Multics' memory-mapped segments=20= > were quite fundamental, of course. I think we were looking for = something=20 > vaguely upward compatible from the existing system calls. We did not=20= > leap to an mmap() right away just because it would have been a more=20 > radical shift than continuing the stream orientation of UNIX. I did = not=20 > implement any of this: it was just a brainstorming session. Thank you for reminding me of these.=20 On a substrate with a unified buffer cache and copy-on-write, = vread/vwrite would have been very close to regular read/write and maybe = could have been subsumed into them, using flags to open() as the = differentiator. The user discernible effect would have been the = alignment requirement on the buffer argument. John Reiser wrote that he "fretted=E2=80=9D over adding a 6 argument = system call. Perhaps he was considering something like the above as the = alternative, I never asked. I looked at the archives and vread/vwrite were introduced with 3BSD, = present in 4BSD but marked deprecated, and absent from 4.1BSD. This = short lifetime suggests that using vread and vwrite wasn=E2=80=99t = entirely satisfactory in 1980/81 practice. Maybe the issue was that = there was no good way to deallocate the buffer after use.