flint@gistdev.UUCP (04/26/89)
If we can have a standardized list of errno values that everybody uses which
match (well, they ought to be standardized anyway) we ought to be able to come
up with a system call that will return standard info about the capabilities
of the machine you are running on. (I don't believe anyone really cares what
the machine is, they care what the capabilities of it are. Getting back what
the machine is is just a kludge way to find out if it has the capability you
are interested in at the time: the same goes for the OS. For example, I don't
really care if I'm running SYSV or BSD4.2, I just want to know if symbolic
links are available. If I'm dumb enough to put in a test that asks whether
I'm using SYSV or BSD to answer that question it will work now, and will break
when SYSV R4.0 comes out.) So why not create something like this to test for
machine capabilities:
long machcap();
if (machcap(CSYMLINK)) {... /* if symbolic links are available */
You then define constants for each capability people might want to test for,
just like you have defined constants (ENOENT, EDEADLOCK) for errno values.
A command can then be created easily for use in scripts, etc. The biggest
problem here is obvious: you're never going to have every capability that
everyone might want to test for in the list, and on any given machine you
are going to have a lot of capabilities in the list that will fall into
obscurity fairly quickly. (ie, "Can this machine execute 68020 instructions"
as a capability or "Can it execute 286 instructions" are things that you will
probably want in the list but which will be fairly worthless in 10 years, just
like the tests for pdp11 machines are now.) But the same goes for the
errno returns, and that hasn't stopped us from trying to make those standard.
(They have been updated somewhat, I've noted: "Not a typewriter", for one
example.) A second problem is what to do with capabilities that exist in
multiple versions: one answer is to define a constant for each version I
suppose, (a prospect I find distasteful), a second alternative might be to
have machcap return not just 0 or 1, but have any positive return indicate
the version level of the capability. Another possibility might be to have
it return a pointer at a struct full of info, but for most capabilities this
is going to be real overkill.
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165
INTERNET: flint%gistdev@uxc.cso.uiuc.edu
UUCP: {uunet,pur-ee,convex}!uiucuxc!gistdev!flintbill@twwells.uucp (T. William Wells) (04/29/89)
Another way to handle different capabilities is to create a directory
containing files corresponding to each capability. (Isn't there
something like this in the latest Unixes?)
That way, things like shells can test them as easily as programs.
/etc/capabilities/symlinks
/etc/capabilities/longnames (containing the number of characters)
/etc/capabilities/cpp (containing the path for cpp)
/etc/capabilities/termcap (containing the library path)
/etc/capabilities/terminfo (containing the library path)
/etc/capabilities/coff
And the possibilities are, unfortunately, endless. :-)
---
Bill { uunet | novavax } !twwells!billscs@adam.pika.mit.edu (Steve Summit) (04/29/89)
In article <8800012@gistdev> flint@gistdev.UUCP correctly points out that: >Getting back what >the machine is is just a kludge way to find out if it has the capability you >are interested in at the time: the same goes for the OS. For example, I don't >really care if I'm running SYSV or BSD4.2, I just want to know if symbolic >links are available. With a bit of creativity, you'll find that many such tests can be performed already, particularly if you can live with compile-time tests. For symbolic links, just #include <sys/stat.h> and then #ifdef S_IFLNK For terminal driver/job control stuff, something like SIGTSTP from <signal.h> often works. Often the predicate for the #ifdef is directly related to what you're about to do: #ifdef SIGWINCH signal(SIGWINCH, resize); #endif If you care about run-time tests (this becomes an issue if you want to move binaries around among various systems which might or might not have the features) you can sometimes get by with judicious return value checking. For example, if your compilation environment supports SIGWINCH but your run environment might not, just ignore an error return from your attempt to catch SIGWINCH (after figuring out what to cast -1 to!) if errno is EINVAL. (Of course, you lose if the target system uses signal 28 for something else.) Steve Summit scs@adam.pika.mit.edu
bzs@bu-cs.BU.EDU (Barry Shein) (04/29/89)
>Another way to handle different capabilities is to...
But the problem is obvious, if they won't standardize their Unix's
what makes you think they'll standardize some method for a program to
discover their non-standardness? Swell, now every vendor will come up
with a variant for *this* so we'll need some sort of new capability to
figure out which capability system they're using...
Besides, who wants to standardize non-standard behavior, better to
standardize and be done with it...
This doesn't mean that every Unix will be identical, it means that a
capability approach will be useless since the enhancements and
modifications will be on the periphery of the OS and nearly impossible
to accomodate in advance by merely discovering the capability later.
That is, figuring out what machine type and/or vendor/version OS is
about all your program should need (if that...) since either your
program understands these unique extensions or it don't, merely
discovering that this machine has time-warp won't tell your program
how to use it. Simple, common differences like symlink support should
fade (or, go back to my first point.)
--
-Barry Shein, Software Tool & Die
There's nothing more terrifying to hardware vendors than
satisfied customers.