Re: [TUHS] Systematic approach to command-line interfaces

["Greg A. Woods" <woods@robohack.ca>]

[-- Attachment #1: Type: text/plain, Size: 2928 bytes --]

At Wed, 29 Sep 2021 09:57:15 -0700, Larry McVoy <lm@mcvoy.com> 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 <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]