Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: Pyramid system design
Message-ID: <5602@sun.uucp>
Date: Tue, 29-Jul-86 14:59:14 EDT
Article-I.D.: sun.5602
Posted: Tue Jul 29 14:59:14 1986
Date-Received: Wed, 30-Jul-86 00:53:23 EDT
References: <1759@brl-smoke.ARPA> <976@decuac.DEC.COM> <459@oracle.UUCP> <5431@topaz.RUTGERS.EDU> <5561@sun.uucp> <5446@topaz.RUTGERS.EDU>
Organization: Sun Microsystems, Inc.
Lines: 113

> Guy Harris expressed disbelief that Pyramid could possibly have
> complete 4.2 and System V universes.  I have no idea whether it is
> possible or not.  I can only say that they have done it.

No, they haven't, if by "complete" you mean one system can look like it has
all of both versions.  As you point out later, you have to choose one
version of "init", "login", etc. and stick with it.  (Also note that, as was
mentioned somewhere, if you want quotas the "chown" call becomes privileged.)

> Their kernel has a full set of 4.2 and SV system calls.  This is not a
> case of an emulation package being done at the library level.

How it's done is totally irrelevant.  In many cases there's no need to
provide them both as system calls; add a "old unreliable V7 signal
mechanism" bit to the "sv_flags" field of the 4.3BSD signal mechanism, and
you can implement *both* flavors of "signal" on top of *one* version of
"sigvec".

> By and large they have a full set of 4.2 and SV utilities.

Nothing special about that.  Given a C library supporting the library
routines of both versions, 99% of the utilities can be built under either
version.

> There are a few cases where this is not true.  E.g. the compilers are
> usually the same

Again, it's not "complete".  Somebody has to make a choice - the vendor, in
this case.  AT&T made the same choice when they switched from the old V7-ish
object file format to COFF; they provided conversion tools but you don't get
old-style versions of "as", "ld", etc. with S5.

> But most things come in both Berkeley and ATT flavors, even things like
> ps

Believe me, doing "ps" ain't that hard.  You aren't going to run the vanilla
S5 "ps" on a kernel which is a modified 4.2BSD kernel, but you can change
the user interface of the 4.2BSD one to look like the S5 one; it's not that
hard.

> and who.  (They actually have separate wtmp's and utmp's, both of which
> contain data for all of the jobs.)

Unless, of course, they get out of sync; another potential source of
headaches.

> There are separate line printer spoolers (which can run at the same time,
> and I think may even be able to share the same printer),

Again, an administrative headache.  (They'd better be able to share the same
printer; painting "S5 only" and "4.2BSD only" on printers would be
unacceptable.)  If they share the same printer, what happens when N jobs
from one universe are ahead of your job from the other universe?  Does a
listing of the queue show both jobs?  If not, I for one would be rather
annoyed; when I ask for a queue listing I expect it to give me a reasonable
idea of when I can expect my job to be printed.  Since the administrator
would have to know about *both* spoolers anyway, why not just provide one
spooler, or two spoolers, capable of supporting *requests* from both command
sets?  The users won't know the difference (their view of the spooler is just
"what commands do I type to make things happen" and "what do those commands
type back at me").

> UUCP's, and mail programs.  Presumably one could have a
> site that had two different UUCP site names, going to the two
> universes.  My guess is that almost all sites run one or the other
> version of UUCP.

I suspect any alternative would be too unwieldy.

As for "mail programs", mail *readers* isn't a problem.  One would hope that
both flavors of "/bin/mail" and both flavors of "Mail" (one called "Mail",
one called "mailx") go through the same *delivery* mechanism; if aliases in
"/usr/lib/aliases" are only available in the 4.2BSD universe, that's bound
to cause a bit of confusion.

> I don't know the exact reason for doing all of this, but I can guess.
> There are certainly commercial accounts who don't want any of this
> Berkeley stuff.  There are Universities who have no interest in ATT.

(If they have no interest in ATT, why are they running UNIX?  *ALL* UNIXes
come ultimately from AT&T; 4.2BSD is a derivative of an AT&T UNIX.  Could we
please use "4.2BSD" and "System V" when talking about these two descendants
of AT&T's Research UNIX, instead of using misleading terms like UCB and ATT?)

There are ways of providing this that don't require the full gore of a dual
port.  You can sell and support two different UNIX ports; some people do
this, although it's a major support headache.  You can provide one kernel
that supports both, and a "common superset" command set along with variants
for the relatively few that are irreconcilably incompatible.

> There are also middle of the road places that would like to be able to
> choose a particular mix of UCB and ATT features that is appropriate
> for their site, and maybe develop programs for both Berkeley and ATT
> Unix with some hope that they will really run on each kind of
> implementation.  It is also possible to mix things, so that you can
> use Berkeley job control in a program that uses SV locking, etc.

Again, that's not hard; you just provide library routines from both
environments - and interfaces to the system calls from both environments -
in the C libraries from both environments.  Of course, you can't call the
system calls for manipulating process groups "setpgrp" and "getpgrp" in the
S5 environment, but you can certainly provide them.

The point is that you *can't* hide the differences.  You *have* to choose
one version of "init", for instance.  And you either have to choose one
version of UUCP or have the administrator support both.  It's not clear that
a 99% solution is enough better than a 97% solution to justify all the extra
gore needed to get that last 2%; the law of diminishing returns takes over.
There ain't no 100% solution.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)


Brought to you by Super Global Mega Corp .com