Dual environments (was: Should \"ls -R\" traverse symlinks?)

[Doug Gwyn]

In article <20099 at adm.BRL.MIL> rbj at dsys.ncsl.nist.gov (Root Boy Jim) writes:
>Sequent uses the dual-universe concept, implemented with csymlinks.
>Their implementation was based on Doug Gwyn's System V environment
>for BSD systems (presumably it has a better name than that). In a private
>communication, he said he preferred Sun's (and presumably that of Ultrix
>and other vendors) approach: whatever mishmash of features you provide,
>make it into one integrated whole. I am sure that if I have misstated
>his views, he will let everyone know.

Several vendors (initially at least) provided System V capability on
their 4BSD-based systems via some form of dual environments.  Pyramid
appears to have been first commercially, although earlier a New York
legal firm ran PDP-11 UNIX systems whose kernels switched between
two "modes" of interpreting system calls, in order to simultaneously
support software supplied by vendors for two different kernel
implementations (Interactive Systems and BRL/JHU).

Numerous computer vendors picked up the BRL UNIX System V emulation for
4.nBSD as the basis for their initial support for the System V
environment.  I deliberately chose not to require kernel changes to
support multiple environments, which limited the extent of the System V
emulation (for example, System V shm facilities had to be omitted) as
well as its accuracy (for example, termio ioctls were closely but not
perfectly emulated).  The goal for BRL was to provide a stable, standard
platform for applications on UNIX-based systems.  The System V emulation
served (and still serves) that goal quite well; now that there are
official UNIX interface standards other than the SVID, the support base
will migrate in a POSIX and possibly X/Open direction.  Fortunately,
that can be done without invalidating the System V environment that we
already depend on.  (My choice of SVID as a base wasn't accidental.)

OS vendors are in a position to modify their kernels to provide better
support for System V applications than I was able to squeeze out of the
native 4BSD kernel.  Several, perhaps most, who picked up the BRL System
V emulation did add some degree of kernel support; for example, Gould
provided a kernel implementation of the three System V-specific IPC
mechanisms in what was otherwise basically a 4.2BSD kernel.  Although
Sun acquired at least one copy of the BRL package, evidence suggests
that they essentially implemented System V support their own way, with
even the use of directories such as /usr/5bin treated in a noticeably
different way from mine.

The most encouraging development is the merging of the major commercial
variants into UNIX System V Release 4.  Particularly the SVR4 kernel
appears to be quite well done, and I would urge vendors who are still
grappling with UNIX variant incompatibilities to seriously consider
adopting SVR4 as the basis for their own OS products.

I don't have a lot of information about the OSF/* variant yet.  If it
provides an SVR4-compatible application programming interface then it
is not a big problem, otherwise it is.  We really didn't need additional
divergence at this point in time, just as we were attaining convergence.