Makeing "Gated"

[Eric Bergan]

In article <129125 at uunet.UU.NET> rbj at uunet.UU.NET (Root Boy Jim) writes:
>In <151920 at pyramid.pyramid.com> eric at pyramid.pyramid.com (Eric Bergan) writes:
>?In article <128287 at uunet.UU.NET> rbj at uunet.UU.NET (Root Boy Jim) writes:
>?>In <151385 at pyramid.pyramid.com> eric at pyramid.pyramid.com (Eric Bergan) writes:
>?	Also, I'm actually less concerned with the library routines than
>?the system call interfaces. Signal semantics, or tty handling tend to
>?be much more difficult to port around. Specifics of memory management
>?also tend to be difficult to blend into a single interface.
>
>It's very simple.
>Start with the ucb universe and snarf anything you need from the att one. 
>Resolve conflicts where they occur.

	Would be nice if it were this simple. Unfortunately, the details
get a little more complex. Lets take signals, for example. Do you
follow the bsd style and not have to reset the signal handler, or the
"standard" att style (yes, I know variants have been introduced) and
require resetting the handler after each signal? Can't have it both
ways in the same API, and yet there are programs that expect each
type of behavior.

>?Or maybe the semantics of kill() - in one universe you can
>?send signals to zombies, not in the other. 
>
>This seems like an accident to me.  Nowhere do you document the difference.
>I don't see what difference it makes or why you'd care.

	Not sure if it was an accident or not - basically when the
bsd re-did the process handling, zombies quite being valid candidates
for signals.

	As for why someone would care - well, without getting philisophical,
all I can say is that at least Oracle required zombies to be valid targets
for signals.

>?	On the otherhand, the back flips necessary to use sockets in
>?an att universe program, or shared memory in a ucb universe program, are
>?overly complex.
>
>They shouldn't be. After all, there is only one kernel, and it 
>(mostly) doesn't care which universe you're in. There should be no
>problems with using shared memory in the ucb universe; it's done
>all the time under Ultrix and SunOS. Even Sequent with their
>dual universe system can do it. I bet even Pyramid can do it!

	I guess I wasn't clear. We're in violent agreement. Where there
is no conflict, I fully agree that the additional functionality should
be offered in the other universe. But so far, there hasn't been enough
of a requirement from our customers to warrant a project being started.
(While not rocket science, its not trivial, either. As with all projects,
there would be a cost associated with doing it, and so far there haven't
been enough requests to justify that cost.)

>?There has always be an item on the "to do" list to
>?open up universe-exclusive functionality (i.e. functionality not
>?available in the other universe), but it has always fallen below the line on
>?the list of features that customers wanted for each new release.
>
>You are wrong. Users do not want dual universes. They want
>(with apologies to the Borg) The Best Of Both Worlds. 

	I'll throw this one open to the general user community. Is this
a hot requirement? If so, please let us know. We've not heard it in the
past. Either post something here, let your favorite sales person
know, or feed it back through the user group.

>?>one should not be thwarted [crosslinking] by the vendors.
>?
>?	How do you view us as thwarting this, if you go to all the
>?trouble? version.o is a nasty surprise the first time, but can be
>?pulled across, just like any other module. (I'm assuming you're talking
>?about building an auxilary library, not linking the routines into
>?libc.a itself.)
>
>No. On our Sequent, I pulled out the mem*, a few str*, and getopt
>(which they hid in some random library) and threw them into libc.a.
>
>I decided that not to copy the IPC stuff, but mainly because I rarely use it.
>
>If version.o doesn't really do anything, why have it?
>I was in a hurry so I gave up and compiled some public domain versions
>and stuffed them into libc.

	version.o was an attempt to allow us to intelligently tell what
rev level of the libraries executables (primarly third party and customers)
were built with. It was not necessarily one of the best solutions to the
problem.

>?Most of our customers are pretty unhappy that semantics of functions and
>?system calls vary from vendor to vendor. They want a standard that
>?everyone abides by. Having vendor-specific decisions about where to
>?be "in between" makes them very unhappy.
>
>Yes, this is a problem. However, your solution has problems as well.
>Which problem is more interesting, the confusion of progress,
>or the frustration of stagnation?

	Well, we have significantly different views of the Pyramid
customer base, but many of the customers that I talk to would actually
like to see less "progress" in our operating systems. They feel that
major new functionality even once a year is too frequent. Basically, they
have production applications to run and maintain, and once these applications
are deployed, they don't really need us to rock the boat with new enhancements.

	I don't want to take this argument too far, because clearly there
are other customers (such as yourselves) that want to see us stay current
with the very latest releases that come out. 

	Balancing between these extremes is difficult. We always
encourage our customers to let us know what they would like to see us
provide. (After all, you are our only source of revenue!) As I've
mentioned, posting here, talking to our sales force, or working through
the user group are all good ways of letting your views be known, and
helping us judge exactly what you want.

>?But that would break some segment of working
>?implementation issues. But that would break some segment of working
>?programs, and I don't think the bulk of our customers would appreciate
>?that.
>
>Neither will they appreciate that their working code on SunOS
>and Ultrix doesn't work. You've got All The Right Stuff, but
>you haven't got it all in one place.

	Some don't have SunOS or Ultrix code - they have stricly SVID compliant
code, for instance. Or POSIX compliant. Also, I don't believe that SunOS
and Ultrix are completely source compatible with each other, either.

>?Again, its not the simple items like strchr/index that
>?concern me as much as the system call semantics that force some
>?of these issues. 
>
>Again, at least half of all portability problems come from
>strchr/index, memcpy/bcopy. Most BSD programs still use signal.

	Actually, a major segment of our customer base is att based.
Not surprising, with both Informix and Oracle being att based. Also with
the large amount of business we do with the RBOCs and AT&T. The att
side customers tend (and this is a generalization, there are exceptions)
to be more insistent about maintaining the "purity" of the att universe
semantics.

>?>?The only true solution
>?>?is a standard that encorporates both, and that is why we are so
>?>?active with SVR4.
>
>[I deleted comments about your "joke" of SVR4 vs OSF universes]
>
>Some private mail with one of your coworkers indicated that
>about half of your technical people would quit if y'all did that.

	I'm among that number, by the way.

>Anyway, I'm glad to see that you're moving towards one system.
>Dual universes were once an intrigueing concept; now they are passe.

	I don't know about passe, but hopefully they won't be necessary
as more strict standards emerge that allow fewer loopholes and
interpretations. But you're right, this will also inhibit innovation,
at least in areas touched by the standards. Some will label this
a sign of "maturity", others "stagnation". I think it is some of both.

-- 

					eric
					...!pyramid!eric