Makeing "Gated"

[Root Boy Jim]

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:
?>?	In general, DON'T DO THIS! Cross universe linking can get very messy.
?>
?>It's only messy because Pyramid made it so...
?>
?>Using the return value from *printf and *scanf is nonportable.
?>Even if malloc is different, it should work either way.
?
?	I think we have different views of what portability means. Yes,
?the return values for printf and scanf are nonportable across varieties
?of UNIX, but that shouldn't make them nonportable between systems claiming
?to support the same subspecies of UNIX.

Nevertheless, using the return value from sprintf is dangerous.
I've given up using it because it has bitten me too many times.
And that's *my* definition of portability.

?	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.

Or, if you must, do it the other way.

?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.

?	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!

?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. 

?>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.

?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?

?	As I mentioned before, supplying index/strchr, or memcpy/bcopy
?are the least of the problems. Much more interesting are the 
?customers that want native streams and native sockets, in the same
?system.

I  think all the noise about streams is merely handwaving. Streams
are basicly a tool for kernel implementors, and not generally
useful to mere users. Oh yeah, they allow you to poll(), a
feature that could have been provided if they just used select.

?	We do, frequently. The dual port is not necessarily fun
?to maintain - it would be great to relax some of the strict
?implementation issues.

I have only seen two dual universe systems, and I hope I never
see another. Both are incredibly antiquated. With twice as much
code to maintain, you do a poor job of keeping up with either
side's progress.

?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.

?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.

?>?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.

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

?>Well, you had better keep you eye on what Berkeley does too.
?
?	We'll continue to watch what they do, but I think the bsd will
?become less of a force in the commercial marketplace. By their own
?statements, Berkeley would like to get their releases back to the
?research basis that they wanted, to investigate computer science issues,
?and not have to worry about 4 zillion vendors calling up to complain
?when there is no upward compatibility, or they don't closely track
?the latest IEEE standard.

BSD is actually more careful with their changes than AT&T is.
Those four zillion vendors would be call them too if they listened.

And BSD may very well become the only UNIX worth having when
it becomes free. The Net supports it better than any vendor can.
-- 
		[rbj at uunet 1] stty sane
		unknown mode: sane