The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Ruizendaal <pnr@planet.nl>
To: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] mmap origin (was Systematic approach to command-line interfaces)
Date: Fri, 1 Oct 2021 13:36:27 +0200	[thread overview]
Message-ID: <D6AFFB70-A58A-43EB-9CF8-C51CDD4F5982@planet.nl> (raw)

Dan wrote:

> 3BSD and I think 4.1BSD had vread() and vwrite(), which looked like 
> regular read() and write() but accessed pages only on demand. I was a 
> grad student at Berkeley at the time and remember their genesis. Bill 
> and I were eating lunch from Top Dog on the Etcheverry Hall plaza, and 
> were talking about memory-mapped I/O. I remember suggesting the actual 
> names, perhaps as a parallel to vfork(). I had used both TENEX and 
> Multics, which both had page mapping. Multics' memory-mapped segments 
> were quite fundamental, of course. I think we were looking for something 
> vaguely upward compatible from the existing system calls. We did not 
> leap to an mmap() right away just because it would have been a more 
> radical shift than continuing the stream orientation of UNIX. I did not 
> implement any of this: it was just a brainstorming session.

Thank you for reminding me of these. 

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” 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’t entirely satisfactory in 1980/81 practice. Maybe the issue was that there was no good way to deallocate the buffer after use.



             reply	other threads:[~2021-10-01 11:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-01 11:36 Paul Ruizendaal [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-09-30  9:01 Paul Ruizendaal via TUHS
2021-09-30 12:56 ` Dan Halbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D6AFFB70-A58A-43EB-9CF8-C51CDD4F5982@planet.nl \
    --to=pnr@planet.nl \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).