Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uakari.primate.wisc.edu!ames!claris!sts!octopus!pyramid!eric
From: eric@pyramid.pyramid.com (Eric Bergan)
Newsgroups: comp.sys.pyramid
Subject: Re: universes in the kernel
Message-ID: <83558@pyramid.pyramid.com>
Date: 7 Sep 89 15:57:37 GMT
References: <1989Sep4.220954.5497@tubsibr.uucp> <83318@pyramid.pyramid.com>
Reply-To: eric@pyramid.pyramid.com (Eric Bergan)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 58

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