hitz@mips.COM (David Hitz) (03/02/88)
I was at the USENIX Sun BOF and got to see a description of some of the
merged UNIX plans. The session was very open and informative, but I do
still have some questions.
As described at the BOF, SunOS 5 is phase I of merged UNIX, and will be
available Q3 or Q4 of this year. It will be SVID compatible and the
default environment for users will be Sys-V-ish. (Surprise! But they
claim it's easy to switch so not to worry.)
In cases where a particular command differs between the two OSs, Sun
will include both versions of the command. The version you get depends
on your path. (Sounded like if you have /usr/ucb first you are in
"BSD-mode" and if you have /bin:/usr/bin first you are in "SYSV-mode", but
that wasn't completely clear ...).
What I'm still curious about is source code compatibility and header
files. For instance, will the current tree of Sys V.3.1 commands build
unmodified under SunOS 5? What about the SunOS 3.X command tree?
If the default environment is really SYSV-ish, that seems to imply that
(1) SYSV commands must build unchanged and (2) the SYSV headers must
be the ones that are really in /usr/include.
But obviously Sun must also want the Sun command tree to build
unchanged. (Note: I'm not really interested in the commands per say.
They are just a convenient body of UNIX user code. If the command
trees won't build unmodified then customer applications probably won't
either. (Possibly excepting some administrative commands.))
So the obvious questions are, how do you specify which style source you
are using? Where do the "old fashioned" Sun style headers go? Is
there some special Sun header directory, kind of like BRL in reverse?
Or maybe nami will be modified to allow BSD and SYSV style users to see
the directory tree differently as some converged UNIXs have done?
Maybe there's a new-and-improved solution I haven't even thought of?
More miscellany: How are hard coded paths in shell scripts and C code
handled? Or shell scripts that don't set PATH explicitely? This only
matters where commands differ, but one needn't search hard to find
differences that could break shell scripts (e.g. /bin/cat, /bin/ls,
/bin/tr, /bin/ps, /bin/nm, ...). Having the default environment be
SYSV would imply that SYSV style shell scripts work fine, but again Sun
would want their stuff to work as well. (Nami hack again?)
Where there are semantic differences like the meaning of the path "",
or whether regular users can chown, is the semantic used determined
by whether the code is compiled as SYSV code or BSD code, or is there
a per user bit that specifies flavor?
I know that these problems are tricky, and maybe the answer for some of
them is simply, "That's too hard to solve perfectly. We will support
only the BSD (or SYSV) behavior." That's a fine answer by me (although
I expect the arguements with ATT aren't much fun :-).
My motivation for asking these questions is this: MIPS -- and probably
other UNIX manufacturers and users -- is very interested in tracking
standards and in what the future of UNIX will be. Right now ATT/Sun
seems to be running with the standards flag, but there isn't much
public information available about where they are taking it. (Working
for a UNIX supplier I'm especially interested in advanced information.)
The Sun BOF was a great start, and I'd like to encourage the flow of
information from ATT/Sun to continue so that the UNIX world isn't taken
by surprise.
--
Dave Hitz DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!hitz DDD: hitz@408-991-0345davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/04/88)
In the current SunOS3 implementation, if the first thing in your path
is "/usr/ucb" you get a BSDish environment, while if it is "/usr/5bin"
you get a SysV environment.
The option works well enough that I have had to select USG rather than
BSD in a number of programs, most recently MicroEMACS. I haven't tried
the current environment for shared memory and semiphores, but that will
be high on my list for SunOS 5.
Hope others have additional info.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -memerlin@hqda-ai.UUCP (David S. Hayes) (03/04/88)
It works well enough that the Oracle RDBMS, which basically was built for VMS and System-V, runs on the Sun. We've been running it successfully under both 3.2 and 3.4. -- David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900 UUCP: *!uunet!cos!hqda-ai!merlin ARPA: ai01@hios-pent.arpa
lm@arizona.edu (Larry McVoy) (03/04/88)
In article <1742@quacky.mips.COM> hitz@quacky.UUCP (David Hitz) writes: >If the default environment is really SYSV-ish, that seems to imply that >(1) SYSV commands must build unchanged and (2) the SYSV headers must >be the ones that are really in /usr/include. Several vendors offer both via conditional symbolic links. There are two trees (sort of) and depending upon what sort of universe you are in you either get a sys5 environment or a BSD environment. I hope that this _not_ what Sun is going to do. Why? Because it perpetuates the problem, rather than attempt a solution. What really needs to be done is to have some smart (set of) person(s) take a long hard look at both kernels and boths sets of command trees. They should come up with a list of items that are a) syntactically and semantically the same (i.e., ARE the same) b) syntactically different but semantically the same c) syntactically the same but semantically different (these exist) d) syntactically and semantically different and resolve the differences. I know it's not quite as bad as you all may be thinking; I put LAI's TCP/IP into a V.3 kernel recently and it shoehorned in all right. Once you've done that you have similar semantics and it's just a question of deciding which are ``best'' and committing to them and providing a compat lib for loose ends. I'll add a plug for System V and then shutup: I grew up (as much as I have :-) on BSD. I went to work and had to deal with system V. It's really pretty nice. It needs a fast file system, and maybe job control (mostly obsoleted by windows), but it has select (they call it poll) and best yet: it has the SVID (System Five Interface Definition) and SVVS (System Five Verification Suite). That amounts to user doc that is _correct_ and a test to prove that the kernel does what the manuals say it does (kernel here means kernel + libs). That's very nice. -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/05/88)
In article <4128@megaron.arizona.edu> lm@megaron.arizona.edu.UUCP (Larry McVoy) writes:
-I hope that this _not_ what Sun is going to do. Why? Because it perpetuates
-the problem, rather than attempt a solution. What really needs to be done is
-to have some smart (set of) person(s) take a long hard look at both kernels
-and boths sets of command trees. They should come up with a list of items
-that are
- a) syntactically and semantically the same (i.e., ARE the same)
- b) syntactically different but semantically the same
- c) syntactically the same but semantically different (these exist)
- d) syntactically and semantically different
-and resolve the differences.
Sun pretty much did this already for SunOS 3.2, so it would be surprising
(not to mention annoying) if they failed to do so for the merged version.
After all, what is "merged" about separate environments?decot@hpisod2.HP.COM (Dave Decot) (03/05/88)
> I hope that this _not_ what Sun is going to do. Why? Because it perpetuates > the problem, rather than attempt a solution. What really needs to be done is > to have some smart (set of) person(s) take a long hard look at both kernels > and boths sets of command trees. They should come up with a list of items > that are > > a) syntactically and semantically the same (i.e., ARE the same) > b) syntactically different but semantically the same > c) syntactically the same but semantically different (these exist) > d) syntactically and semantically different > > and resolve the differences. This is what POSIX and X/Open are trying to do at the moment. > Once you've done that you have similar semantics and it's just > a question of deciding which are ``best'' and committing to them and > providing a compat lib for loose ends. You have just described HP-UX 2.0. HP-UX conforms to SVID (except NSE, at the moment), and includes job control, select, interval high-resolution timers, process/data memory locking, ksh, shell layers, RCS, X, ARPA/BSD networking, preemptable kernel, "contiguous" files, BSD-style fast file system, symbolic links, long file names, multiple group IDs per process, NFS, SIGIO, and lots of non-SVID System V stuff. All in a system that passes the SVVS. You get System V and non-conflicting BSD stuff by default; if you want the BSD version of a something that conflicts (a "loose end"), you just link in an extra library. Dave Decot hpda!decot
jc@minya.UUCP (John Chambers) (03/05/88)
> In the current SunOS3 implementation, if the first thing in your path > is "/usr/ucb" you get a BSDish environment, while if it is "/usr/5bin" > you get a SysV environment. > There's one thing very different that has bitten me lately; maybe some reader out there has the perfect solution. On a couple of Suns I've been working on, I have a need of running a different program on some ports than /etc/getty; I'd also like to run some background daemons not associated with a port, and guarantee that they will be restarted if they die. On Sys/V (in fact, on all Unices I've ever seen except BSD and Sun), this is easy. You just edit the /etc/inittab file, and put whatever programs you want in the command. F'rinstance, if your inetd or sendmail insists on bombing every 37 hours or so, you remove the command that starts it from /etc/rc and put it into /etc/inittab, with 'respawn' in the 3rd field. On BSD/Sun systems, init seems to come hard-wired with knowledge of /etc/getty; there's only an /etc/ttys file to say where to run getty; there's no /etc/inittab file at all. This seems like a major loss, as it eliminates a large class of killable daemons. The only solution I've heard so far is to supplant /etc/getty with my own program that has its own control file (I'm tempted to call it "/etc/inittab" :-), which tells it where to run the real getty and where to run something else. Sure, I could do this, but it seems a whole lot like re-inventing a wheel that comes with all other Unix systems. Anyone got a better solution? Perhaps RTFM, with page numbers? Is there a Sys/V init lurking somewhere in Sun's libraries? Is there a PD version of init that I can install? -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>) (03/09/88)
In article <14020014@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes:
:> [someone's comments on combining SysV and BerkOS by using common]
:> [commands and resolving semantic differences ]
:HP-UX conforms to SVID (except NSE, at the moment), and includes job control,
:select, interval high-resolution timers, process/data memory locking,
:ksh, shell layers, RCS, X, ARPA/BSD networking, preemptable kernel,
:"contiguous" files, BSD-style fast file system, symbolic links, long
:file names, multiple group IDs per process, NFS, SIGIO, and lots of
:non-SVID System V stuff. All in a system that passes the SVVS.
Guess the SVID/SVVS must not be picky about setpgrp() behaviour. To give
HP-UX credit, they document their somewhere-in-between solution well,
and it's not clear there *is* a right way to resolve the differences.
I must say, just having a System V with sockets is a pleasant start,
and they've done a lot more.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# So we got out our profilers and debuggers and editors and various other
# implements of destuction and went off to clean up the tty driver...decot@hpisod2.HP.COM (Dave Decot) (03/11/88)
> Guess the SVID/SVVS must not be picky about setpgrp() behaviour. The setpgrp() in libc.a on HP-UX fully conforms to SVID. To support job control functions, we added a system call named setpgrp2() that does what BSD setpgrp() does (except that we added some needed security checks). To make it easier to compile BSD programs without changing your source files, we also provide a routine called setpgrp() in libBSD.a; that routine just calls setpgrp2(). > To give HP-UX credit, they document their somewhere-in-between solution well, > and it's not clear there *is* a right way to resolve the differences. POSIX will avoid this by not specifying a function named setpgrp(), but naming both sets of functionalities something else. > I must say, just having a System V with sockets is a pleasant start, > and they've done a lot more. Thanks for the encouragement. I'm glad you're pleased. Dave Decot hpda!decot
karish@denali.UUCP (karish) (03/12/88)
In article <14020020@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >POSIX will avoid this by not specifying a function named setpgrp(), >but naming both sets of functionalities something else. The last time I looked at my copy of Draft 12 of the 1003.1 standard, it specified two functions, called setpgrp() and jcsetpgrp(). Have I missed something? My employer is not so foolish as to agree with all of my opinions. Chuck Karish ARPA: karish@denali.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish paper: 1825 California St. #5 Mountain View, CA 94041