hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (07/29/86)
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. 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. By and large they have a full set of 4.2 and SV utilities. There are a few cases where this is not true. E.g. the compilers are usually the same (but the libraries are not, of course. So the compilers produce real ATT programs on the ATT side and real UCB programs on the UCB site.) Also, you get a real UCB C shell even on the ATT side. (This is in some sense a violation of their design philosophy. Presumably they decided that supplying a C shell where ^Z is intentionally disabled is carrying purity too far, particularly since csh isn't really part of SV anyway. There are separate Bourne shells.) But most things come in both Berkeley and ATT flavors, even things like ps and who. (They actually have separate wtmp's and utmp's, both of which contain data for all of the jobs.) 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), 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 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. 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. As for init, yes there are two inits. Of course you don't run them both at once. But the system administrator gets to choose which one he wants. They each read the set of startup and configuration files that you would expect for that version. init and login are the primary places where you can't have both universes active at once. However the logins each know how to deal with both universes. They can each start jobs in either universe. (The user can choose which he wants.)
guy@sun.uucp (Guy Harris) (07/29/86)
> 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)
hutch@sdcsvax.UUCP (Jim Hutchison) (07/30/86)
In article <5446@topaz.RUTGERS.EDU> hedrick@topaz.RUTGERS.EDU (Charles Hedrick) writes: >I don't know the exact reason for doing all of this, but I can guess. Yet another consideration is the fact that you can write code that is portable between the two "universes" and test this fact immediately, without 2 machines. You can also do (pardon sudden relegious urge :-) work in the universe you prefer for the vile universe (the one you may feel some disdain for). Being spoiled by unclean but useful job control and such does not make me not want to use things like streams and shared memory. Yes, I realize pyramids don't have streams, but its the concept! Working in an environment different from your test environment and being on the same machine. Like sitting on a sun doing ms-dos work via cross-compiler, but without having to change machines (or even have 2 machines). -- Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: Hutch@sdcsvax.ucsd.edu "When you are going to die, a wombat is better than no company at all." -RZ
wallen@sdics.UUCP (Mark Wallen) (07/30/86)
I can think of two other reasons why Pyramid may have chosen to implement two complete sets of utilities (i.e., 4.2 ones and sysV ones). The first is the porting cost; if you REALLY have a sysV system, why screw around with a 4.2 utility? Just bring up the sysV one. And visa versa. The second is a little recursive, but: what better way to test a sysV port that to bring up (by simply compiling) it's idiosyncratic utilites (e.g., uucp); if they work, you have a sysV port. If not, ??? Mark Wallen UC San Diego
zben@umd5 (Ben Cranston) (08/01/86)
In article <1958@sdcsvax.UUCP> hutch@sdcsvax.UUCP (Jim Hutchison) writes: > Yes, I realize pyramids don't have streams, but its the concept! Working in > an environment different from your test environment and being on the same > machine. Hmm, sort of like doing your compiles under CMS and then firing up an MVS in a virtual machine to test them? :-) -- umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92 umd2.BITNET "via HASP with RSCS"