petri (Stefan Petri) (09/05/89)
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@tubsibr.UUCP>
Technische Universitaet Braunschweig, Institut fuer Betriebssysteme und
Rechnerverbund, 3300 Braunschweig, W. Germany.csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/05/89)
In article <1989Sep4.220954.5497@tubsibr.uucp> petri@tubsibr.UUCP (Stefan Petri) writes: >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 : There are two parts to the dualport. - Conditional symbolic links are evaluated at run time, based on the current "universe" of the process. The universe is a number in the process's u-area. - There are two complete and independent set of system calls -- a complete BSD set, and a complete System V set. (Look in /usr/include/syscalls.h.) System call numbers are coded into the libraries, and the libraries are of course bound to the program by ld. In other words, the universe in which a program is compiled (and loaded) will determine which system calls it uses. The runtime 'universe' will determine which file trees the program "sees." Examples: ucb cat /usr/include/stdio.h The Berkeley 'cat' lists the Berkeley stdio.h. ucb /.attbin/cat /usr/include/stdio.h The SVR3 'cat' lists the Berkeley stdio.h. att cat /usr/include/stdio.h The SVR3 'cat' lists the att stdio.h As far as kill(2) is concerned, the two calls are completely different inside the kernel, though I'm not really up to figuring out why. <csg>
eric@pyramid.pyramid.com (Eric Bergan) (09/07/89)
In article <83318@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >In article <1989Sep4.220954.5497@tubsibr.uucp> petri@tubsibr.UUCP (Stefan Petri) writes: >>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 : > >In other words, the universe in which a program is compiled (and loaded) will >determine which system calls it uses. More fully, it is determined by the library (referenced through the universe-dependent symbolic link) that has the universe specific version of the system call in it. That is why extracting the kill.o from the att library, and linking it into a "bsd" binary still results in it calling the att kill system call. >As far as kill(2) is concerned, the two calls are completely different inside >the kernel, though I'm not really up to figuring out why. The main difference is that under att, you can deliver signals to zombie's, which you can't under bsd. To maintain the proper semantics in both universes, you need two different system calls. WARNING: After reading this, some of you will realize you can start trying to pull att functionality into the bsd universe, or vice versa, by yanking things out of libraries and building new ones. THIS IS UNSUPPORTED. There are areas of problems. For instance, trying to pull bsd signals into the att universe can effect far more than you intend it to (sleep, alarm, wait, ...) Cross universe linking of library functions is definitely not supported - there are lots of pitfalls there - different semantics between the universes (*printf, for instance), also incompatabilities in structure definitions (FILE is different in the two universes, hence stdio is different.) Most of all - do not try something like bsd cc -o foo foo.c /.attlib/libc.a I.E. Trying to include the whole alternate universe libc. Almost guarenteed to not work - particularly if you do anything with stdio. Likewise for trying to do att cc -o foo foo.c /.ucblib/libc.a We are aware that it would be nice if there were a "merged" universe, or some way to access the "missing" functions from the other universe, safely in all applications. We are studying the issues, but are certainly not in a position to announce either a product, upgrade, or product direction at this time. -- eric ...!pyramid!eric