30 Sep
2021
30 Sep
'21
11:31 p.m.
At Wed, 29 Sep 2021 09:57:15 -0700, Larry McVoy <lm(a)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:
Implementation isn't really what I meant to talk directly about -- I
meant "integration", and especially integration outside the kernel.
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. 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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>