Path: utzoo!attcan!uunet!husc6!mit-eddie!apollo!gallen From: gallen@apollo.uucp (Gary Allen) Newsgroups: comp.unix.wizards Subject: Re: Re: O'pain Software Foundation: (2) Why is it better than AT&T? Message-ID: <3c805988.4bee@apollo.uucp> Date: 6 Jun 88 17:18:00 GMT References: <637@spectrix.UUCP> <11410001@eecs.nwu.edu> Reply-To: gallen@gallen.UUCP (Gary Allen) Organization: Apollo Computer, Chelmsford, MA Lines: 68 In article <11410001@eecs.nwu.edu> naim@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