The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] mmap origin (was Systematic approach to command-line interfaces)
@ 2021-09-30  9:01 Paul Ruizendaal via TUHS
  2021-09-30 10:39 ` [TUHS] Early shared library implementations arnold
  2021-09-30 12:56 ` [TUHS] mmap origin (was Systematic approach to command-line interfaces) Dan Halbert
  0 siblings, 2 replies; 10+ messages in thread
From: Paul Ruizendaal via TUHS @ 2021-09-30  9:01 UTC (permalink / raw)
  To: TUHS main list


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.
> 
> Perhaps these "add-on hack" problems are the reason so many people think
> fondly of the good old Unix versions where everything was still coming
> from a few good minds that could work together to build a cohesive
> design.  The add-ons were poorly done, not widely implemented, and
> usually incompatible with each other when they were adopted by
> additional implementations.

mmap() did come from those days and minds.

The first appearance of mmap() was in 32V R3, done by John Reiser in 1981. This is the version of 32V with full demand paging; it implemented a unified buffer cache. According to John, that version of mmap() already had the modern 6 argument API. John added mmap() because he worked with Tenex a lot during his PhD days and missed PMAP. He needed some 6 months to design, implement and debug this version of 32V as a skunkworks project.

I am trying to revert early VAX SVr1/r2 code to get a better view of what 32V R3 looked like, but unfortunately I did not have much time for this effort in last couple of months. It would seem that 32V R3 assumed that disk blocks and memory pages were the same size (true on a 1980 VAX) and with that assumption a unified buffer cache comes natural in this code base.

For 4.2BSD initially Joy cs. had a different approach to memory mapped files in mind (see the 1981 tech report #4 from CSRG). By the time of 4.2BSD’s release the manual defined a mmap() system call, but it was not implemented and it appears to have been largely forgotten until SunOS 4 and dynamic libraries six years later.

In the SysV lineage it is less clear. For sure mmap() is not there, but the first implementation of the shmem IPC feature might derive from the 32V R3 code. On the inside, SVr2 virtual memory appears to implement the segments (now called regions) that Joy envisaged for 4.2BSD but did not implement.

CB Unix had a precursor to shmem as well, where a portion of system core was reserved for shared memory purposes and could be accessed either via the /dev/mem device or could be mapped into the PDP-11 address space (using 1 of the 8 segment registers for each map). Here too the device and the map were unified.

So far, I have not come across any shared library implementations or precursors in early Unix prior to SunOS 4.

Paul


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [TUHS] Early shared library implementations
  2021-09-30  9:01 [TUHS] mmap origin (was Systematic approach to command-line interfaces) Paul Ruizendaal via TUHS
@ 2021-09-30 10:39 ` arnold
  2021-09-30 14:12   ` Charles H Sauer
                     ` (2 more replies)
  2021-09-30 12:56 ` [TUHS] mmap origin (was Systematic approach to command-line interfaces) Dan Halbert
  1 sibling, 3 replies; 10+ messages in thread
From: arnold @ 2021-09-30 10:39 UTC (permalink / raw)
  To: tuhs, pnr

Paul Ruizendaal via TUHS <tuhs@minnie.tuhs.org> wrote:

> So far, I have not come across any shared library implementations or
> precursors in early Unix prior to SunOS 4.

In more or less the same time frame, the AT&T UnixPC / 3B1, which was
OEM'ed from Convergent, had shared libraries.  This was ~ 1986.

I don't know the details of how it worked and how one built the shared
libraries; I am sure that it was an independent implementation from Sun's.

This was done on top of a System V Release 2 kernel.  Later versions
of the OS had some bits of the SVR3 user land, but the kernel remained
SVR2 based.

There is a 3B1 emulator and disk images for it available for anyone
who really wants to go back to a system with short filenames and no
job control. :-)

Arnold

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] mmap origin (was Systematic approach to command-line interfaces)
  2021-09-30  9:01 [TUHS] mmap origin (was Systematic approach to command-line interfaces) Paul Ruizendaal via TUHS
  2021-09-30 10:39 ` [TUHS] Early shared library implementations arnold
@ 2021-09-30 12:56 ` Dan Halbert
  1 sibling, 0 replies; 10+ messages in thread
From: Dan Halbert @ 2021-09-30 12:56 UTC (permalink / raw)
  To: tuhs

On 9/30/21 5:01 AM, Paul Ruizendaal via TUHS wrote:
> For 4.2BSD initially Joy cs. had a different approach to memory mapped files in mind (see the 1981 tech report #4 from CSRG). By the time of 4.2BSD’s release the manual defined a mmap() system call, but it was not implemented and it appears to have been largely forgotten until SunOS 4 and dynamic libraries six years later.
>
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.

Dan H

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Early shared library implementations
  2021-09-30 10:39 ` [TUHS] Early shared library implementations arnold
@ 2021-09-30 14:12   ` Charles H Sauer
  2021-10-11  6:43   ` Rob Gingell via TUHS
  2021-10-17 22:15   ` Chris Hanson
  2 siblings, 0 replies; 10+ messages in thread
From: Charles H Sauer @ 2021-09-30 14:12 UTC (permalink / raw)
  To: tuhs

On 9/30/2021 5:39 AM, arnold@skeeve.com wrote:
> Paul Ruizendaal via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
>> So far, I have not come across any shared library implementations or
>> precursors in early Unix prior to SunOS 4.
> 
> In more or less the same time frame, the AT&T UnixPC / 3B1, which was
> OEM'ed from Convergent, had shared libraries.  This was ~ 1986.
> 
> I don't know the details of how it worked and how one built the shared
> libraries; I am sure that it was an independent implementation from Sun's.
> 
> This was done on top of a System V Release 2 kernel.  Later versions
> of the OS had some bits of the SVR3 user land, but the kernel remained
> SVR2 based.
> 
> There is a 3B1 emulator and disk images for it available for anyone
> who really wants to go back to a system with short filenames and no
> job control. :-)

I'm very hazy on the details, because I wasn't directly involved, but we 
had shared libraries in AIX for the RT starting with the initial release 
in 1986 (based on SVR1). Larry Loucks did most of the design, with help 
from ISC folks and maybe Rick Simpson. Larry mentions this work in our 
AIX 2 paper 
(https://technologists.com/sauer/Advanced%20Interactive%20Executive%20(AIX)%20Operating%20System%20Overview.pdf) 
but I don't see any useful description, nor do I see anything useful 
skimming http://www.bitsavers.org/pdf/ibm/pc/rt/ docs. A more 
sophisticated shared library design was one of the additions in AIX 3.

Charlie

P.S. That paper and 
https://technologists.com/sauer/SA23-1057_IBM_RT_Personal_Computer_Technology_1986.pdf 
do include a bit more discussion of our memory mapped files since 
support for those was a primary goal of the 801 virtual memory design 
(summarized in the "Rosetta" paragraph of 
https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/). 


-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Twitter: CharlesHSauer

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Early shared library implementations
  2021-09-30 10:39 ` [TUHS] Early shared library implementations arnold
  2021-09-30 14:12   ` Charles H Sauer
@ 2021-10-11  6:43   ` Rob Gingell via TUHS
  2021-10-11  7:08     ` George Michaelson
  2021-10-17 22:19     ` Chris Hanson
  2021-10-17 22:15   ` Chris Hanson
  2 siblings, 2 replies; 10+ messages in thread
From: Rob Gingell via TUHS @ 2021-10-11  6:43 UTC (permalink / raw)
  To: tuhs

On 9/30/2021 2:01 AM, Paul Ruizendaal via TUHS wrote:
> So far, I have not come across any shared library implementations or
> precursors in early Unix prior to SunOS 4.

On 9/30/2021 3:39 AM, arnold@skeeve.com wrote:
> In more or less the same time frame, the AT&T UnixPC / 3B1, which was
> OEM'ed from Convergent, had shared libraries.  This was ~ 1986.

On 9/30/2021 7:12 AM, Charles H Sauer wrote:
> ... A more > sophisticated shared library design was one of the additions in AIX 3.

There was also SVR3 (which I believe was the basis for the referenced 
AIX 3 shared library work). SVR3 shipped in 1987, SunOS 4 in May 1988.

There was a swarm of UNIX shared library projects during the 1980s. Some 
of those preceded or were occurring contemporaneously with SunOS 4. Many 
reached at least a running prototype stage, perhaps deployed as specials 
for customers, and some reached product status.

Some of the projects had papers published and there are a few old 
manuals available through bitsavers.org.

To fill out the history a bit, here are three (including SVR3) that had 
papers published. They also serve to illustrate the different approaches 
being taken. I can not find on-line copies of the papers, but others may 
have better luck or will have access to paper copies of the conference 
proceedings. SVR3 has extensive documentation on bitsavers.org, as does 
some older editions of UTek.

The three projects are:

1. a 68000-based 7th Edition port;
2. UTek: Tektronix's version of 4BSD for their workstations; and
3. System V Release 3.

The first project had a paper published as part of the USEnix track of a 
UniForum Conference in January 1984 and was titled "Transparent 
Implementation of Shared Libraries" and authored by C.B. Downing and F. 
Farance.

The other two had papers published in the 1986 Atlanta Summer USEnix 
proceedings and were: "A New Virtual-Memory Implementation for UNIX" by 
E. W. Sznyter, P. Clancy, and J. Crossland (UTek); and "Shared Libraries 
on UNIX System V" by J. Q. Arnold.

A very thorough description of the SVR3 shared library mechanism is 
available at:

http://bitsavers.org/pdf/att/unix/System_V_Release_3/308-139_UNIX_System_V_Release_3_Programmers_Guide_1987.pdf

Some UTek documentation, including their mmap specification but 
appearing to pre-date their shared libraries work, is available at:

http://bitsavers.org/pdf/tektronix/6130_4132/

For the "Transparent Implementation..." paper, the "transparent" 
referred to a goal that an application's source code not be modified to 
link with shared libraries. That, and sharing, were about the only goals 
common to all the projects of the era. Nearly every other design choice 
varied across the projects as determined by the approach taken or the 
constraints under which the project operated.

On the subject of mmap's origins: UTek used mmap, but specified mmap to 
take a pid instead of a file descriptor for the source of the mapping. 
It appears they contemplated an fmap to map from a file. So for sharing 
to occur, there was to be a daemon that scooped up and relocated in its 
address space all the libraries to be shared and then advertise what it 
had. Client processes would rendezvous with the daemon at runtime and 
map the portions of that process they required to accomplish the sharing.

A common characteristic of these 3 projects was that symbols were 
resolved at ld-time, necessitating some external coordination about how 
address spaces were to be laid out but minimizing run-time overheads. 
The referenced SVR3 documentation provides a good description of the 
considerations involved.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Early shared library implementations
  2021-10-11  6:43   ` Rob Gingell via TUHS
@ 2021-10-11  7:08     ` George Michaelson
  2021-10-11 14:22       ` Clem Cole
  2021-10-17 22:19     ` Chris Hanson
  1 sibling, 1 reply; 10+ messages in thread
From: George Michaelson @ 2021-10-11  7:08 UTC (permalink / raw)
  To: gingell; +Cc: TUHS main list

My memory is, that at least one model (OSF/1) required reboot, because
it did some intermediate call optimisation to remove/elide indirect
refs. Possibly a mis-remember.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Early shared library implementations
  2021-10-11  7:08     ` George Michaelson
@ 2021-10-11 14:22       ` Clem Cole
  0 siblings, 0 replies; 10+ messages in thread
From: Clem Cole @ 2021-10-11 14:22 UTC (permalink / raw)
  To: George Michaelson; +Cc: TUHS main list

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

On Mon, Oct 11, 2021 at 3:09 AM George Michaelson <ggm@algebras.org> wrote:

> My memory is, that at least one model (OSF/1) required reboot, because
> it did some intermediate call optimisation to remove/elide indirect refs.

Hmm, as far as I know,/my experience was that with OSF/1 was fine with
shared libs, no reboot needed (at least on the 386 reference -- I never
tried it on the PMAX].
I suspect you might be thinking about drivers and kernel modules, which
were not nearly as clean - particularly in the pure (Mach 3.0 based) OSF/1
microkernel implementation [which was hardly 'micro' in size].   IIRC Rob's
new memory system code for SunOS was one of the first UNIX implementations
that supported loadable kernel modules.

Anyway, for the original OSF/1, I really don't think shared libs caused a
reboot using the original CMU Mach 2.5 memory code, but adding things to
the kernel did. I know that was changed with the MMU rewrite for Tru64, but
I think it was also done in later versions of the OSF RI kernel (but I've
forgotten).

[-- Attachment #2: Type: text/html, Size: 2012 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Early shared library implementations
  2021-09-30 10:39 ` [TUHS] Early shared library implementations arnold
  2021-09-30 14:12   ` Charles H Sauer
  2021-10-11  6:43   ` Rob Gingell via TUHS
@ 2021-10-17 22:15   ` Chris Hanson
  2 siblings, 0 replies; 10+ messages in thread
From: Chris Hanson @ 2021-10-17 22:15 UTC (permalink / raw)
  To: arnold; +Cc: tuhs, pnr

On Sep 30, 2021, at 3:39 AM, arnold@skeeve.com wrote:
> 
> In more or less the same time frame, the AT&T UnixPC / 3B1, which was
> OEM'ed from Convergent, had shared libraries.  This was ~ 1986.
> 
> I don't know the details of how it worked and how one built the shared
> libraries; I am sure that it was an independent implementation from Sun's.
> 
> This was done on top of a System V Release 2 kernel.  Later versions
> of the OS had some bits of the SVR3 user land, but the kernel remained
> SVR2 based.

Apple A/UX was also SVR2-based and had shared libraries. I wonder if it was a similar implementation. (The porting work for A/UX was initially done by UniSoft, from what I recall.)

  — Chris
 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Early shared library implementations
  2021-10-11  6:43   ` Rob Gingell via TUHS
  2021-10-11  7:08     ` George Michaelson
@ 2021-10-17 22:19     ` Chris Hanson
  1 sibling, 0 replies; 10+ messages in thread
From: Chris Hanson @ 2021-10-17 22:19 UTC (permalink / raw)
  To: gingell, Rob Gingell via TUHS

On Oct 10, 2021, at 11:43 PM, Rob Gingell via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
> There was also SVR3 (which I believe was the basis for the referenced AIX 3 shared library work). SVR3 shipped in 1987, SunOS 4 in May 1988.
> 
> There was a swarm of UNIX shared library projects during the 1980s. Some of those preceded or were occurring contemporaneously with SunOS 4. Many reached at least a running prototype stage, perhaps deployed as specials for customers, and some reached product status.

I believe NEXTSTEP 1.0 supported shared libraries out of the box too, probably from work on Mach or the Andrew system at CMU.

  — Chris


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] mmap origin (was Systematic approach to command-line interfaces)
@ 2021-10-01 11:36 Paul Ruizendaal
  0 siblings, 0 replies; 10+ messages in thread
From: Paul Ruizendaal @ 2021-10-01 11:36 UTC (permalink / raw)
  To: TUHS main list

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.



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-10-17 22:19 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-30  9:01 [TUHS] mmap origin (was Systematic approach to command-line interfaces) Paul Ruizendaal via TUHS
2021-09-30 10:39 ` [TUHS] Early shared library implementations arnold
2021-09-30 14:12   ` Charles H Sauer
2021-10-11  6:43   ` Rob Gingell via TUHS
2021-10-11  7:08     ` George Michaelson
2021-10-11 14:22       ` Clem Cole
2021-10-17 22:19     ` Chris Hanson
2021-10-17 22:15   ` Chris Hanson
2021-09-30 12:56 ` [TUHS] mmap origin (was Systematic approach to command-line interfaces) Dan Halbert
2021-10-01 11:36 Paul Ruizendaal

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ https://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git