jdarcy@seqp4.sequoia.com (Jeff d'Arcy) (06/04/91)
scottl@convergent.com (Scott Lurndal): >Since there is no standards requirement for /dev/kmem (and our implementation >of SVR4.0 for the 88100 does not even have one), how portable is any library >that attempts to extract data from an operating system? To be called unix, >you must provide certain functionality (defined by the SVID and perhaps >XPG3). You do not have to internally look anything like unix as provided >by AT&T (System V) or Berkeley (BSD 4.x); certainly you don't have to use >the same symbol names! Yeah, I've seen a few other vendors who are "minimally compliant" but not truly conformant to U*X norms, and you know what? They're annoying as hell! Renamed utilities, lack of a /dev/kmem interface, and missing or broken library/syscall options (such as ioctls) are just some of the symptoms. Companies who create these almost-UNIX OSes conform to the standards only because they're afraid of customers who demand standards compliance, but if you look deeper you see that they're really not *committed* to open systems and interoperability, that they retain the now-discredited proprietary mentality which used to be such a pain. In the particular case of /dev/kmem it's certainly not necessary to use the same symbol names, but it sure would be nice to have the *interface* (or at least *some* interface) available so that kernel hackers can at least get to the information they want from user-land. You never know *which* variable we might want to look at next, so it would be polite to leave something with a namelist lying around too, although I know of only one vendor which fails in that particular regard. BTW, please respond to jdarcy@encore.com rather than the address in the .sig (which I'm too lazy to change just now) or the header. This is my last day here. -- Jeff d'Arcy, Generic MTS, Sequoia Systems Inc. <jdarcy%seqp4@m2c.org> Time flies like an arrow; fruit flies like a banana