Subject: Re: userid partitioned swap spaces.
To: None <email@example.com>
From: Christoph Badura <firstname.lastname@example.org>
Date: 12/17/1998 18:25:09
email@example.com (Greg A. Woods) writes:
>I had thought VM was in SysVr2.2 on VAX and 3B2, but I can't remember
>for sure. There were certainly lots of systems with SysVr2.2 user-land
>stuff that did not have VM. Although I've used 3B2's running 2.2, that
>was a *long* time ago, and I never got too far inside of them back then.
IIRC, when we got 2.2 on the m68k boxen that included "demand paging"
as opposed to swapping in the whole process on startup and after that.
>Although SysVr4 was first developed on 3B2's AT&T attempted to get lots
>of independent hardware manufacturers to do "reference" ports, however
>not every hardware vendor used the reference port, or at least didn't
>stick very close to it, and some SysVr4 platforms deviated quite a long
>ways from what AT&T was shipping, SunOS-5 being a primary example (and
>Commodore's Amiga port being the least deviant independent port I know
>of, and Pyramid DC/OSx being perhaps the second least deviant one, at
>least in user-land [the DC/OSx kernel is quite a bit different]).
This is somewhat inaccurate. First, there wasn't a single source tree at
AT&T^WUSL for SVR4. Pretty much all the i386/PC versions of SVR4.0 that
the various vendors produced (Dell, ESIX, Generics, Onsite) were derived
from the same USL reference sources, which was a completely separate source
tree from the 3B2 sources (different config mechanism, different source
layout). Second, SunOS5 can't really be described as being SVR4. They
joined forces initially with USL but by the time 4.0.2 became available
they had split again and were going their own way.
>I'm pretty sure all of this is covered clearly and in some detail in
>Bach's "The Design of the Unix Operating System" (did I get that
Since Bach's book only covers SVR2.2 it is pretty unlikely that it documents
any later developments.
>I'd also like to see some discussion as to whether or not the SIGDANGER
>solution might work reliably for UVM....
I think that is the wrong approach. The system shouldn't overcommit VM
except when the application *explicitly* requests it.