universes in the kernel

Stefan Petri petri
Tue Sep 5 08:09:54 AEST 1989


On our Targon/35 (Nixdorf's Pyramid-Clone), I just discovered /etc/scstat (1M)
(the top-twenty-syscalls-of-the-second).

I would like to RTFM, but we only have the german translations of the
Sys5-Manuals (sigh).
As far as I can see out of these manuals, the only difference
between the universes is when following conditional links in the file system,
and this view-of-the-universe has worked fine for me so far, but now :

# cat test.c
main()
{ 
	for (;;) kill(0,0);
}
# att cc -o atttest test.c
# ucb cc -o ucbtest test.c
# ucbtest &
[1] 27012
# atttest & 
[2] 27013
# scstat -o top20 5 1
# cat top20
Total calls/sec 12148. By (CPU) (0) 6263	(1) 5885	

ALL CPU_____________calls/sec__%time
            att kill     6420   48.5
            ucb kill     5721   51.4
            ucb read      < 1    0.2
            ucb open      < 1    0.0
        ucb recvfrom      < 1    0.0
[some more lines deleted]

The output of scstat makes me wonder, if the kernel really executes the
att-sys-calls differently than the ucb-sys-calls (even the "simple" and
common ones like kill() ) .

If I run only one of the *test's, the displayed universe is independent from
the calling shell's universe, but it depends on the compile-time-universe.
Then I extracted the kill.o from /.[att,ucb]lib/libc.a into [att,ucb]kill.o
respectively and did
# att cc -o att2test ucbkill.o test.c
# ucb cc -o ucb2test attkill.o test.c
to compile the test-programs with the library-routines of the other universe.
Now the universe displayed by scstat follows the universe the kill.o came from.
That would mean, it's something in the libraries, that does the difference
at the kernel-level.
But what is this distinction good for, and how does it work, and does
it make any difference for writing programs ?
Can anybody tell me more about it ?

S.P.

--
Stefan Petri					<petri at tubsibr.UUCP>
Technische Universitaet Braunschweig, Institut fuer Betriebssysteme und
Rechnerverbund, 3300 Braunschweig, W. Germany.



More information about the Comp.sys.pyramid mailing list