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

[Guy Harris]

> Unfortunately, I posted the anecdotal tale of this instead of obtaining the
> facts; my apologies.

Apology accepted, but unnecessary; the problem is that it wasn't clear to what
you were referring.  I thought you were saying that they explicitly made sure
that a variety of procedures increased the system CPU time; in fact, they
were just *assuming* that certain procedures increased the system CPU time for
the purposes of testing.  In either case, the assumption being made by the SVVS
is bogus; all they should assume is that the *sum* of user and system time
increases - and even there, they shouldn't assume that it increases by a
measureable amount after a certain amount of real time, but should run in a
loop until at least certain amount of real *and* (user+system) CPU time have
passed.

> I checked with the person in the know and here are the facts:
> 
> In the file time.c,

Presumably you mean "times.c" here.

> there are messages to be printed out to the effect that time (both user and
> system) are not increasing. On closer inspection of this, those messages
> only appear if the time DECREASES.

In which case, it appears to print a message claiming that there was "No change
in {user,system} time", which is a misleading message.  "times.c" is buggy; it
should be fixed as specified above.

> In the file exec1.c, there are messages indicating that the child process
> did not inherit the system and user times of its parent. However, the test
> actually only checks to see that the times are NON-ZERO. This appears to
> have been the sticking point for Apollo since our system time was always 0.

In this case, they should test whether the *sum* of user+system time is
non-zero.

I don't think any of this is the result of a deliberate decision to require
that certain procedures be "system calls" whose CPU time is counted as "system
time", it's just the result of naive assumptions about implementations and of
careless programming.  Of course, the reason *why* they botched the SVVS isn't
the high-order bit, the fact that it was botched is.

Perhaps you should try to present this as a test failure due to a bug in SVVS,
rather than presenting it as a test failure for which a waiver should be
approved?  After all, your system would be *in*compliant with the SVID if it
charged time spent in user mode as "system time", unless certain user-mode
library routines are to be counted as part of "the system".  Requiring you to
make your system incompliant with the SVID in order to get it to pass SVVS
makes no sense whatsoever....