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=-1.0 required=5.0 tests=MAILING_LIST_MULTI
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 4519 invoked from network); 28 Sep 2021 18:10:40 -0000
Received: from minnie.tuhs.org (45.79.103.53)
  by inbox.vuxu.org with ESMTPUTF8; 28 Sep 2021 18:10:40 -0000
Received: by minnie.tuhs.org (Postfix, from userid 112)
	id 3B89B9CB13; Wed, 29 Sep 2021 04:10:37 +1000 (AEST)
Received: from minnie.tuhs.org (localhost [127.0.0.1])
	by minnie.tuhs.org (Postfix) with ESMTP id 9C1629CAE4;
	Wed, 29 Sep 2021 04:10:19 +1000 (AEST)
Received: by minnie.tuhs.org (Postfix, from userid 112)
 id A2FC49CAE4; Wed, 29 Sep 2021 04:10:17 +1000 (AEST)
Received: from mcvoy.com (mcvoy.com [192.169.23.250])
 by minnie.tuhs.org (Postfix) with ESMTPS id 02C139CAE3
 for <tuhs@tuhs.org>; Wed, 29 Sep 2021 04:10:17 +1000 (AEST)
Received: by mcvoy.com (Postfix, from userid 3546)
 id AA60335E17A; Tue, 28 Sep 2021 11:10:16 -0700 (PDT)
Date: Tue, 28 Sep 2021 11:10:16 -0700
From: Larry McVoy <lm@mcvoy.com>
To: The Unix Heritage Society mailing list <tuhs@tuhs.org>
Message-ID: <20210928181016.GN18305@mcvoy.com>
References: <20210731142533.69caf929@moon>
 <CABH=_VR-tfenCLE=DeNcb2ahPjG80v6Ma+W0sRt2jAfy2OX4hg@mail.gmail.com>
 <CAEoi9W4jmzZB-thocbMrZ+B-bnU5bE-q0BsJ6bimw1V6mpUkeA@mail.gmail.com>
 <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu>
 <CAEoi9W5Us72G_rxGogEd2FUh1cJdcf0GzR--omC4RFP-hzuQ_w@mail.gmail.com>
 <CAD2gp_TGGWhKu-uUYN77Y-AnBnY8tTxgcOpfPv-4PNRjgL=idw@mail.gmail.com>
 <CAD-qYGqWynaEDFZKSeuAApn9H9jJL36ombAzxrSV=VGVU46Gdg@mail.gmail.com>
 <m1mVHBR-0036wTC@more.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m1mVHBR-0036wTC@more.local>
User-Agent: Mutt/1.5.24 (2015-08-30)
Subject: Re: [TUHS] 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 <tuhs.minnie.tuhs.org>
List-Unsubscribe: <https://minnie.tuhs.org/cgi-bin/mailman/options/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=unsubscribe>
List-Archive: <http://minnie.tuhs.org/pipermail/tuhs/>
List-Post: <mailto:tuhs@minnie.tuhs.org>
List-Help: <mailto:tuhs-request@minnie.tuhs.org?subject=help>
List-Subscribe: <https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=subscribe>
Errors-To: tuhs-bounces@minnie.tuhs.org
Sender: "TUHS" <tuhs-bounces@minnie.tuhs.org>

On Tue, Sep 28, 2021 at 10:46:25AM -0700, Greg A. Woods wrote:
> The "unix" nod to
> single level storage by way of mmap() suffers from horribly bad design
> and neglect.

I supported Xerox PARC when they were redoing their OS as a user space
application on SunOS 4.x.  They used mmap() and protections to take
user level page faults.  Yeah, there were bugs but that was ~30 years
ago.

In more recent times, BitKeeper used mmap() and protections to take the
same page faults (we implemented a compressed, XORed file storage that
filled in "pages" on demand, it was a crazy performance improvement)
and that worked on pretty much every Unix we tried it on.  Certainly
worked on Linux first try.

So what is it about mmap you don't like?