O'pain Software Foundation: (2) Why is it better than AT&T?

[Gary Allen]

In article <11410001 at eecs.nwu.edu> naim at eecs.nwu.edu (Naim Abdullah) writes:
>Nat Mishkin writes:
>>I think the lesson
>>to be learned from the Apollo experience with SVVS is that at least in
>>some ways it's hard to be innovative (or even just to stray from the
>>AT&T implementation, of which SVVS is supposed to be independent) yet
>>pass SVVS.
>>  In at least some ways, SVVS as it is currently constituted
>>thus stifles innovation.  I think stifling innovation is something none
>>of us want.
>
>Could you be more specific about why Apollo finds it difficult to
>pass SVVS ? I read in Unix Review sometime ago that there is an OS
>which is NOT based on proprietary AT&T source code and yet it comes very
>close to passing the SVVS (I *think* only a couple of tests amongst 7000
>or so tests in the SVVS, failed). Also, Sun has been very innovative
>in the last couple of years and yet they either already pass SVVS 
>(I am not sure if they do or not) or can come very close to it.
>
>Why do you think SVVS depends upon the AT&T implementation of Unix ?
>Can you give us any specifics ? This is not rhetoric. I am genuinely
>curious.

To start with, Apollo's Domain/OS does indeed pass SVVS; it is not a native
kernel.

To site one instance of something that might be considered "implementation
specific" is that SVVS assumes that system calls (those things from chapter
2) really are system calls. Some of the tests invoke "system calls" and then
check that the "system time" increased as a result. This implies that not
only must a particular subroutine work as specified (totally reasonable), but
must also be a system call (arguable), and must have the side effect of
incrementing a global variable (questionable).

For instance, our write(2) is not a system call; it is a library call that makes
use of our file/virtual memory mapping (very similar to the unimplemented
4.2bsd 'mmap' call). Our write simply copies data to a piece of library-
controlled virtual memory to which the file had been previously mapped during
the 'open' call (which in our case is not a system call either, but does in
fact make a system call to do the mapping). I believe that Sun and HP have
implemented similar facilities in their most recent VM implementations.

Since our system does lots of stuff like this via our shared libraries, we
have never had the dichotomy of user/system time. Therefore, our 'system'
time (pre-SVVS) was always 0 with the *actual* (not profiled) time accredited
to user time. When AT&T "flunked" us on this one, a waiver was requested and
denied (we did get a couple of others). In order to pass, half the time was
credited to sys, the other half to user. We passed SVVS, but had lots of
complaints and problems with benchmarks (which also assume such things).
Since then, we put in profiled times which are more accurate but still don't
exactly match a native UNIX due to the library/system call mismatch, and
suck up cycles that could be used to execute user processes.

Caveats: I didn't actually do any of this myself; 'write' was just an example,
I don't know which system calls were being measured; I don't claim that our
way is better; I don't claim AT&T was wrong, unfair or arbitrary; I don't
represent anybody (I do have a strange little brother who claims to represent
God). Flames to /dev/upyours.

Gary Allen
Apollo Computer
Chelmsford, Ma
{decvax,yale,umix}!apollo!gallen

Roses are red
Violets are blue
Most poems rhyme
But I seem to have trouble making mine do that