logier@cheops.qld.tne.oz.au (Rob Logie) (04/08/91)
I have got the source for gated release2 from cornell. I am trying to make it under the UCB universe and it complains about not being able to find "memory.h" Has any one any ideas how to get around this (Pyramid seems to have memory.h only in the att universe. If I try to compile under ATT I get a whole new lot of problems) or better still if someone has some src/Makefile.* files that are configured correctly for the Pyramid I would be greatfull if you could mail them to me . I am using OSX 5.0. Thanks in Advance -- Rob Logie EMAIL: logier@cheops.qld.tne.oz.au Telecom Australia FAX: +61 7 837 4704 TNE Computer Support Services PH: +61 7 837 5174 Brisbane Office "These are my opinions alone"
keyvan@pyra.co.uk (Keyvan Shirnia Pre Sales) (04/09/91)
In article <1991Apr8.073344.2646@cheops.qld.tne.oz.au> logier@cheops.qld.tne.oz.au (Rob Logie) writes: >I am trying to make it under the UCB universe and it complains about >not being able to find "memory.h" > >Has any one any ideas how to get around this (Pyramid seems to have memory.h >only in the att universe. If I try to compile under ATT I get a whole new >lot of problems) or better still if someone has some src/Makefile.* files >that are configured correctly for the Pyramid I would be greatfull if you >could mail them to me . Well memory.h is only defined in ATT. (That is the definition) Some other operating systems might have memory.h in their UCB environment, but that is not true UCB! I am not quite sure what kind of errors your are getting. However, the first thing I would try out would be: (Type this in your ATT universe shell) cc -I/usr/.attinclude -I/usr/.ucbinclude gated.c -o gated /.ucblib/libc.a This line should pickup both the UCB and ATT include files. From the linking point of view, since you are already in ATT universe /.attlib/libc.a is automatically searched. But to be sure that you are not missing any UCB routines add /.ucblib/libc.a . If you got any more problems with this, PLEASE do send me an e-mail. Best regards, Keyvan -m------- Keyvan Shirnia Tel : +44 252 373035 ---mmm----- Pre Sales Support -----mmmmm--- Pyramid Technology Ltd. keyvan@pyra.co.uk -------mmmmmmm- Farnborough GU14 7NA, England. "God is real unless declared integer!"
guy@auspex.auspex.com (Guy Harris) (04/10/91)
> Some other operating systems might have memory.h in their UCB environment, > but that is not true UCB! Gosh, I guess that operating system generally known as "4.3-tahoe" isn't "true UCB", then, 'cuz it has "memory.h" in the only environment it offers: /* * Copyright (c) 1985 Regents of the University of California. * All rights reserved. The Berkeley software License Agreement * specifies the terms and conditions for redistribution. * * @(#)memory.h 5.1 (Berkeley) 85/08/05 */ /* * Definitions of the Sys5 compat memory manipulation routines */ extern char *memccpy(); extern char *memchr(); extern int memcmp(); extern char *memcpy(); extern char *memset(); I guess just because it came from Berkeley's CSRG doesn't mean it's really BSD, then, by that logic....
eric@pyramid.pyramid.com (Eric Bergan) (04/10/91)
In article <671136511.AA15442@flaccid> keyvan@pyra.co.uk (Keyvan Shirnia) writes: >In article <1991Apr8.073344.2646@cheops.qld.tne.oz.au> logier@cheops.qld.tne.oz.au (Rob Logie) writes: >>I am trying to make it under the UCB universe and it complains about >>not being able to find "memory.h" >> >>Has any one any ideas how to get around this (Pyramid seems to have memory.h >>only in the att universe. If I try to compile under ATT I get a whole new >>lot of problems) or better still if someone has some src/Makefile.* files >>that are configured correctly for the Pyramid I would be greatfull if you >>could mail them to me . > >Well memory.h is only defined in ATT. (That is the definition) Some other >operating systems might have memory.h in their UCB environment, but that >is not true UCB! > >I am not quite sure what kind of errors your are getting. However, the >first thing I would try out would be: (Type this in your ATT universe shell) > >cc -I/usr/.attinclude -I/usr/.ucbinclude gated.c -o gated /.ucblib/libc.a > >This line should pickup both the UCB and ATT include files. From the linking >point of view, since you are already in ATT universe /.attlib/libc.a is >automatically searched. But to be sure that you are not missing any UCB >routines add /.ucblib/libc.a . In general, DON'T DO THIS! Cross universe linking can get very messy. If you do the above, for instance, you will get the ucb signal semantics. If your program expects the att semantics, then you're in trouble. This is widespread through the libraries - *printf and *scanf have subtle differences, malloc is a different algorithm, etc. Doing the above (explicitly calling the ucb library) will cause all references that can be resolved from the ucb library to be. This is not supported, and can lead to very strange problems. Note that occasionally this will work fine. You might not get bitten. But it is simply wrong in the general case. Even extracting the necessary modules from the other universe's library can be a problem - you need to check what referenced externals there are, and make sure they won't have problems in the other universe. We can get philisophical about whether it was better to stay strictly compliant with the ucb and att standards, or to blend them together and get something that wouldn't necessarily be compliant with either. Basically its a no win situation - for every customer that would like a blended environment, another would like one where their strictly compliant program would work. The only true solution is a standard that encorporates both, and that is why we are so active with SVR4. -- eric ...!pyramid!eric
rbj@uunet.UU.NET (Root Boy Jim) (04/11/91)
In article <151385@pyramid.pyramid.com> eric@pyramid.pyramid.com (Eric Bergan) writes: >In article <671136511.AA15442@flaccid> keyvan@pyra.co.uk (Keyvan Shirnia) writes: >>In article <1991Apr8.073344.2646@cheops.qld.tne.oz.au> logier@cheops.qld.tne.oz.au (Rob Logie) writes: >>>I am trying to make it under the UCB universe and it complains about >>>not being able to find "memory.h" >> >>Well memory.h is only defined in ATT. (That is the definition) Some other >>operating systems might have memory.h in their UCB environment, but that >>is not true UCB! The Tahoe distribution has memory.h. >>I am not quite sure what kind of errors your are getting. However, the >>first thing I would try out would be: (Type this in your ATT universe shell) >> >>cc -I/usr/.attinclude -I/usr/.ucbinclude gated.c -o gated /.ucblib/libc.a >> >>This line should pickup both the UCB and ATT include files. From the linking >>point of view, since you are already in ATT universe /.attlib/libc.a is >>automatically searched. But to be sure that you are not missing any UCB >>routines add /.ucblib/libc.a . I am surprised someone from Pyramid suggested this, as it doesn't work. Pyramid put some nasty stuff to keep you from cross-linking. > In general, DON'T DO THIS! Cross universe linking can get very messy. It's only messy because Pyramid made it so. I pulled out the memory stuff, getopt, and some string functions from Sequent's ATT libc.a and put them in the UCB libc.a because I was tire of dealing with it. >If you do the above, for instance, you will get the ucb signal >semantics. If your program expects the att semantics, then you're in >trouble. This is widespread through the libraries - *printf and *scanf >have subtle differences, malloc is a different algorithm, etc. Using the return value from *printf and *scanf is nonportable. Even if malloc is different, it should work either way. >Doing >the above (explicitly calling the ucb library) will cause all references >that can be resolved from the ucb library to be. This is not supported, >and can lead to very strange problems. I agree that the librarys are linked in the wrong order. If someone expects the att default behavior, the att lib should come first. My situation was the exact opposite: I used "-lc /usr/att/lib/libc.a" in the ucb universe on a Sequent. > Note that occasionally this will work fine. You might not >get bitten. But it is simply wrong in the general case. Even extracting >the necessary modules from the other universe's library can be a >problem - you need to check what referenced externals there are, and >make sure they won't have problems in the other universe. Yes, things can get tricky, but if one goes to all the trouble of doings so, one should not be thwarted by the vendors. > We can get philisophical about whether it was better to stay >strictly compliant with the ucb and att standards, or to blend them >together and get something that wouldn't necessarily be compliant >with either. We don't have to get philosophical; the answer is clear. Ten years ago dual universes were kinda neat. You could satisfy people from both camps on the same machine, and it was a marketing plus. However, the world is moving towards a merged system. At least half of the portability problems I see have to do with the index/strchr or memcpy/bcopy dichotomy. Why not supply both? The att and ucb environments are not so much universes as galaxies within the same universe. At one end of the spectrum is att, at the other, ucb. Real implementations are somewhere in between, with features of both. If you want a separate universe, make it a VMS one. >Basically its a no win situation - for every customer >that would like a blended environment, another would like one >where their strictly compliant program would work. This may have once been true. Better repoll your customers. It has been said that there is no such thing as portability, only programs that have been ported. Strict compliance may also lead to tunnel vision. Besides, which version of the standard is a program strictly compliant with? I don't know how well Pyramid has kept up with System V, but you are sure behind on BSD. You still have 4.2 signals! >The only true solution >is a standard that encorporates both, and that is why we are so >active with SVR4. Well, you had better keep you eye on what Berkeley does too. -- [rbj@uunet 1] stty sane unknown mode: sane
keyvan@pyra.co.uk (Keyvan Shirnia Pre Sales) (04/11/91)
In article <128287@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: > >The Tahoe distribution has memory.h. > Memory.h might well be there, however, this is a superset of the *MAIN STREAM* UCB. I am not saying that Tahoe is not UCB, though :-) >>>I am not quite sure what kind of errors your are getting. However, the >>>first thing I would try out would be: (Type this in your ATT universe shell) >>> >>>cc -I/usr/.attinclude -I/usr/.ucbinclude gated.c -o gated /.ucblib/libc.a >>> >>>This line should pickup both the UCB and ATT include files. From the linking >>>point of view, since you are already in ATT universe /.attlib/libc.a is >>>automatically searched. But to be sure that you are not missing any UCB >>>routines add /.ucblib/libc.a . > >I am surprised someone from Pyramid suggested this, as it doesn't work. >Pyramid put some nasty stuff to keep you from cross-linking. I did try to say that this cc line *might* work. It is very difficult to figure out exactly what library routines you need to compile a piece of unknown code. You are right, however, that I should have stressed this fact! > >> In general, DON'T DO THIS! Cross universe linking can get very messy. > >It's only messy because Pyramid made it so. I pulled out the memory >stuff, getopt, and some string functions from Sequent's ATT libc.a >and put them in the UCB libc.a because I was tire of dealing with it. Well this is exactly what Sun have done. It's just another way of approaching the problem. I myself have ported many programs to Pyramid, and used the cross linking of the universes. I have only once come across such a problem, and that was with scanf(). > >>Doing >>the above (explicitly calling the ucb library) will cause all references >>that can be resolved from the ucb library to be. This is not supported, >>and can lead to very strange problems. Cross-linking may not be supportable, however, the original question was that the code did not compile under the att universe. I never said that the cc line would work. (I only suggested that it might work, or give some clues as to what the problem is) Programs cross referencing different universes are never portable. Neither is your own-built Sequent ucb libc.a which also contains some att routines. This it self is cross linking. The syntax might have changed but semmantically it is the same. > >> Note that occasionally this will work fine. You might not >>get bitten. But it is simply wrong in the general case. Even extracting >>the necessary modules from the other universe's library can be a >>problem - you need to check what referenced externals there are, and >>make sure they won't have problems in the other universe. > >Yes, things can get tricky, but if one goes to all the trouble of >doings so, one should not be thwarted by the vendors. Again I stress the point that if you are the programmer you should take this in to account. However, if you are trying to port a software across, then surely you have no choice. Well you can always rewrite the software, I guess! :-) Best regards, Keyvan -m------- Keyvan Shirnia Tel : +44 252 373035 ---mmm----- Pre Sales Support -----mmmmm--- Pyramid Technology Ltd. keyvan@pyra.co.uk -------mmmmmmm- Farnborough GU14 7NA, England.
kre@cs.mu.OZ.AU (Robert Elz) (04/12/91)
keyvan@pyra.co.uk (Keyvan Shirnia Pre Sales) writes: >Well memory.h is only defined in ATT. (That is the definition) Some other >operating systems might have memory.h in their UCB environment, but that >is not true UCB! That's an obsolete notion of what BSD is ... memory.h appeared in BSD in 4.3 (years ago). There's not supposed to be any noticeable difference between the BSD mem*() functions (which is what memory.h is all about) so you should be able to simply copy (or link) the ATT universe memory.h into the UCB universe on a pyramid. Unfortunately, I suspect that this may be just pushing the problem back one layer, as if memory.h isn't in pyramid's UCB universe, then its almost certain that the mem*() functions aren't in the libc in its UCB universe either. You may be able to get around that by linking with the ATT universe libc *after* the UCB universe libc - which means that you'll need to explicitly name that on the cc (or ld) command line, not just default to it. The BSD mem*() functions are supposed to be exact functional duplicates of the Sys V versions - though the true BSD versions don't make any pretence to be effecient - they were just added to make it easier to move Sys V progs to BSD, and in general improve compatability between the two). kre ps: I'm pretty sure of all of this, except what might work on the Pyramid, as I put all this stuff in BSD just before 4.3 was released.
rbj@uunet.UU.NET (Root Boy Jim) (04/13/91)
In article <kre.671424242@mundamutti.cs.mu.OZ.AU> kre@cs.mu.OZ.AU (Robert Elz) writes: >keyvan@pyra.co.uk (Keyvan Shirnia Pre Sales) writes: > >>Well memory.h is only defined in ATT. (That is the definition) Some other >>operating systems might have memory.h in their UCB environment, but that >>is not true UCB! > >That's an obsolete notion of what BSD is ... memory.h appeared in BSD >in 4.3 (years ago). I don't believe that it was in the original 4.3. At least it's not documented in the manual sets that you get from Usenix (or us). It may have been hidden away in some System V compatibility library directory in the source tree, however. In any case, it's certainly been available for quite some time. The Tahoe version has a copyright date of 85/08/05, which predates 4.3. It appears that vendors who chase dual universes can't keep up with either one. Sequent does just as bad of a job. >You may be able to get around that by linking with the ATT universe libc >*after* the UCB universe libc - which means that you'll need to explicitly >name that on the cc (or ld) command line, not just default to it. Perhaps I wasn't explicit enuf. Sequent lets you mix and match. Pyramid, on the other hand, puts a reference to either __ucblibc_Id_ or __attlibc_Id in every object in the library, except for version.o, which defines same. So yes, you can use both librarys. I just ran the following program main(){printf("memcmp(\"foo\",\"bar\") = %x\n",memcmp("foo","bar"));} with the command line: cc -o qaz qaz.c -lc /.attlib/libc.a The answer, btw, is 4. I suppose I can pull out both version.o and add them to each library along with anything else I want to cross-pollenate. -- [rbj@uunet 1] stty sane unknown mode: sane
kre@cs.mu.oz.au (Robert Elz) (04/13/91)
rbj@uunet.UU.NET (Root Boy Jim) writes: >I don't believe that it was in the original 4.3. At least it's not >documented in the manual sets that you get from Usenix (or us). I didn't say I documented them ... I rarely document anything, the mem*() functions were added to make it easier to port Sys V code to BSD, not because anyone was expected to actually write new code using them. I mean, who'd use strchr() if index() is available... >Perhaps I wasn't explicit enuf. Sequent lets you mix and match. >Pyramid, on the other hand, puts a reference to either This part of my answer was mere speculation - I haven't used a pyramid in a very long time. But apart from strchr() and strrchr() (which were just index & rindex renamed) the other mem*() functions in BSD were all written from scratch, so the sources of them should be able to be made available, and freely copied, should you want to add them to your BSD universe library. If you need strchr() (etc), you can use the -Dstrchr=index trick. kre
eric@pyramid.pyramid.com (Eric Bergan) (04/15/91)
In article <128287@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >In article <151385@pyramid.pyramid.com> eric@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. I pulled out the memory >stuff, getopt, and some string functions from Sequent's ATT libc.a >and put them in the UCB libc.a because I was tire of dealing with it. > >>If you do the above, for instance, you will get the ucb signal >>semantics. If your program expects the att semantics, then you're in >>trouble. This is widespread through the libraries - *printf and *scanf >>have subtle differences, malloc is a different algorithm, etc. > >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. malloc's syntax may be common (well, malloc(0) is a little unclear) but since different time/space tradeoffs are made, the end result on the suitability of the program that is built can be dramatic. 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. Or maybe the semantics of kill() - in one universe you can send signals to zombies, not in the other. 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. 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. >> Note that occasionally this will work fine. You might not >>get bitten. But it is simply wrong in the general case. Even extracting >>the necessary modules from the other universe's library can be a >>problem - you need to check what referenced externals there are, and >>make sure they won't have problems in the other universe. > >Yes, things can get tricky, but if one goes to all the trouble of >doings so, one should not be thwarted 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.) >> We can get philisophical about whether it was better to stay >>strictly compliant with the ucb and att standards, or to blend them >>together and get something that wouldn't necessarily be compliant >>with either. > >We don't have to get philosophical; the answer is clear. Ten years >ago dual universes were kinda neat. You could satisfy people >from both camps on the same machine, and it was a marketing plus. > >However, the world is moving towards a merged system. At least >half of the portability problems I see have to do with the >index/strchr or memcpy/bcopy dichotomy. Why not supply both? > >The att and ucb environments are not so much universes as >galaxies within the same universe. At one end of the spectrum >is att, at the other, ucb. Real implementations are somewhere >in between, with features of both. Unfortunately, this is not true of the older releases. 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. 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. >If you want a separate universe, make it a VMS one. Well, we have talked about SVR4 and OSF/1 (and maybe NT)... (The above is a joke, and should in no way be considered a statement of product direction for Pyramid!!!) >>Basically its a no win situation - for every customer >>that would like a blended environment, another would like one >>where their strictly compliant program would work. > >This may have once been true. Better repoll your customers. >It has been said that there is no such thing as portability, >only programs that have been ported. Strict compliance >may also lead to tunnel vision. We do, frequently. The dual port is not necessarily fun to maintain - it would be great to relax some of the strict implementation issues. But that would break some segment of working programs, and I don't think the bulk of our customers would appreciate that. 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. >>The only true solution >>is a standard that encorporates both, and that is why we are so >>active with SVR4. > >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. -- eric ...!pyramid!eric
rbj@uunet.UU.NET (Root Boy Jim) (04/16/91)
In <151920@pyramid.pyramid.com> eric@pyramid.pyramid.com (Eric Bergan) writes: ?In article <128287@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: ?>In <151385@pyramid.pyramid.com> eric@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@uunet 1] stty sane unknown mode: sane
guy@auspex.auspex.com (Guy Harris) (04/16/91)
>>That's an obsolete notion of what BSD is ... memory.h appeared in BSD >>in 4.3 (years ago). > >I don't believe that it was in the original 4.3. I believe it was, because I checked the directory tree containing the source from the 4.3BSD tape here, and there's a "memory.h" in "/usr/src/include".
eric@pyramid.pyramid.com (Eric Bergan) (04/22/91)
In article <129125@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >In <151920@pyramid.pyramid.com> eric@pyramid.pyramid.com (Eric Bergan) writes: >?In article <128287@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >?>In <151385@pyramid.pyramid.com> eric@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
rbj@uunet.UU.NET (Root Boy Jim) (04/24/91)
In <152790@pyramid.pyramid.com> eric@pyramid.pyramid.com (Eric Bergan) writes: ?In article <129125@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: ?>In <151920@pyramid.pyramid.com> eric@pyramid.pyramid.com (Eric Bergan) writes: ?>?In article <128287@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: ?>?> <151385@pyramid.pyramid.com> eric@pyramid.pyramid.com (Eric Bergan) writes: We really should start our own newsgroup :-) ?>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. Of course the details get hairy, but the basic idea is simple. And you won't get anything done if you sit around lamenting about how hard it is. ?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. You assume neither style and explicitly reset the signal handler inside the handler itself. Portable to either environment. I don't think any program insists that signals be unreliable in the window between entering the handler and resetting the signal. ? 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. Sending signals to zombies is clearly meaningless. Some one should tell this to Oracle. Fix the right piece of code. ? 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.) A very short sighted decision. That's why you're so far behind DEC and Sun. You're going to have to do the work anyway, so you might as well start doing it now. ?>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. Unfortunately, "hot requirements" have little to do with The Right Thing. ?>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. OK. Once a year, you sync up with BSD, Sun, AT&T, and whoever else you think is an industry leader. Take a year to port and release it. You can't even keep to that schedule. ? 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. It's not how far you take the argument; the problem is that you're going in the wrong direction. Yes, progress must be tempered. ? Balancing between these extremes is difficult. We always ?encourage our customers to let us know what they would like to see us ?provide. Of course, it is another thing to heed those words. ?(After all, you are our only source of revenue!) Not any more. ?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. We want what Berkeley had FIVE YEARS AGO! HOW LOUD DO WE HAVE TO SAY THIS? ?>?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. You neglect to mention that AT&T regularly breaks code and has its own share of gratuitous changes as well. First they rotated the manual sections, then they made you buy the DWB to get online manuals. Ln(1) is now broken. Consider: rm -f a b; touch a b; ln a b; Historicly, the ln has always failed. Now it succeeds. I am not aware of many other System V bugs because I rarely use it. ?>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. No, but much closer than with Pyramid. And you're not POSIX compliant now either. ? Actually, a major segment of our customer base is att based. Because you don't treat your Berkeley customers right. ?>[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, You don't know about passe, but you'll quit if they do? Make up your mind. -- [rbj@uunet 1] stty sane unknown mode: sane