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 30407 invoked from network); 30 Sep 2021 17:32:04 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 30 Sep 2021 17:32:04 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id F130F9CBB5; Fri, 1 Oct 2021 03:32:01 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id DEEE59CB95; Fri, 1 Oct 2021 03:31:25 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id F34129CB95; Fri, 1 Oct 2021 03:31:22 +1000 (AEST) Received: from central.weird.com (unknown [198.96.117.51]) by minnie.tuhs.org (Postfix) with ESMTP id 15D079CB92 for ; Fri, 1 Oct 2021 03:31:22 +1000 (AEST) Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for 'more.local': Unknown host)more.local ((no PTR matching greeting name)d207-6-82-137.bchsia.telus.net[207.6.82.137] port=64369) by central.weird.com([198.96.117.51] port=587) via TCP with esmtp (5928 bytes) (sender: ) (ident using UNIX) id for ; Thu, 30 Sep 2021 13:31:20 -0400 (EDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #78 built 2020-Mar-25) Received: from (invalid client hostname: the DNS A record (with the targegt address [10.0.1.129]) for the hostname 'more.local' does not match the expected address [10.0.1.129])more.local ((no PTR matching greeting name)xentastic.local[10.0.1.140] port=60159) by more.local([10.0.1.129] port=25) via TCP with esmtp (5422 bytes) (sender: ) id for ; Thu, 30 Sep 2021 10:31:20 -0700 (PDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2015-Feb-17) Message-Id: Date: Thu, 30 Sep 2021 10:31:20 -0700 From: "Greg A. Woods" To: The Unix Heritage Society mailing list In-Reply-To: <20210929165715.GN18305@mcvoy.com> References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> <20210928181016.GN18305@mcvoy.com> <20210929165715.GN18305@mcvoy.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/26.1 (x86_64--netbsd) MULE/6.0 (HANACHIRUSATO) X-Face: ; j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --pgp-sign-Multipart_Thu_Sep_30_10:31:03_2021-1 Content-Type: text/plain; charset=US-ASCII At Wed, 29 Sep 2021 09:57:15 -0700, Larry McVoy wrote: Subject: Re: [TUHS] Systematic approach to command-line interfaces > > On Wed, Sep 29, 2021 at 09:40:23AM -0700, Greg A. Woods wrote: > > I think perhaps the problem was that mmap() came too soon in a narrow > > sub-set of the Unix implementations that were around at the time, when > > many couldn't support it well (especially on 32-bit systems -- it really > > only becomes universally useful with either segments or 64-bit and > > larger address spaces). The fracturing of "unix" standards at the time > > didn't help either. > > I think you didn't use SunOS 4.x. mmap() was implemented correctly > there, the 4.x VM system mostly got rid of the buffer cache (the > buffer cache was used only for reading directories and inodes, there > was no regular file data there). If you read(2) a page and mmap()ed > it and then did a write(2) to the page, the mapped page is the same > physical memory as the write()ed page. Zero coherency issues. Implementation isn't really what I meant to talk directly about -- I meant "integration", and especially integration outside the kernel. > This was not true in other systems, they copied the page from the > buffer cache and had all sorts of coherency problems. It took > about a decade for other Unix implementations to catch up and I > think that's what you are hung up on. Such implementation issues are just a smaller part of the problem, though obviously they delayed the wider use of mmap() in such broken implementations. The fact wasn't even available at all on many kernel implementations at the time (the way open(2), read(2), write(2), et al were/are), is equally important too of course -- 3rd party software developers effectively wouldn't use it because of this. So, the main part of the problem to me is that mmap() wasn't designed into any unix deprived or unix-like system coherently (i.e. including at user level) (that I'm aware of). It wasn't integrated into languages or system libraries (stdio f*() functions could probably even have used it, since I think that's how stdio was (or could have been) emulated on Multics for the C compiler and libc). It all reminds me of how horrible the socket(2)/send(2)/sendmsg(2) hack is -- i.e. socket descriptors should have just been file descriptors, opened with open(2). I guess pipe(2) kind of started this mess, and even Plan 9 didn't seem to do anything remarkable to address pipe creation as being subtly different from just using open(2). Maybe I'm going to far with thinking pipe() could/should have just been a library call that used open(2) internally, perhaps connecting the descriptors by opening some kind of "cloning" device in the filesystem. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms --pgp-sign-Multipart_Thu_Sep_30_10:31:03_2021-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCYVX0WwAKCRBie18UwlnH hWhzAKC6d7gvh/e/x3qxIf30aXkEu0wsAgCg8tH92TgcgJ1Wojow+dNGVNwoUBo= =ypoe -----END PGP SIGNATURE----- --pgp-sign-Multipart_Thu_Sep_30_10:31:03_2021-1--