🚀 go-pugleaf

guy@Auspex.COM (Guy Harris) writes:

>The SVR4 documentation I have indicates that the "sysinfo()" routine
>will, if given the "command" SI_ARCHITECTURE, return "a string
>describing the instruction set architecture of the current system, e.g.,
>'mc68030', 'm32100', or 'i80486'."

>It also hints that said "command" is used by "uname -p" to return the
>"processor type" string.

>Unfortunately, as I read it, that *doesn't* correspond to the ABI to
>which the machine conforms:

Uname -p is inended as the generic processor type, but was not firmly
enough specified to guarantee that.  The MIPS ABI Group Technical
Committee wrestled with this problem for a while, decided that there
simply hadn't been enough standardization on sysinfo (esp. amongst the
members of that group!) and defined a series of extensions to sysinfo
to handle the needs of that ABI.  Comments were submitted (I believe)
to the ABICC (UI's ABI Coordinating Committee), but I don't know the
results.  I'll look into it, however.

>	the same presumably applies to other ABIs for processors for
>	architectures that have acquired new instruction over time.

>A *program* probably doesn't have to care what the ABI is for the
>machine on which it's running - if it's the wrong ABI, it won't run,
>period - but a *script* might care.  In particular, Frame Maker has a
>"fmarch" script that, at least on some platforms, is used to select the
>directory from which executables are to be run.

Programs may care about other issues - what _version_ of the ABI,
for example, or the detailed processor type (for (yuck) licensing
reasons. There's an open can of worms here.

>If, in fact, "uname -p" returns a *detailed* processor type, rather than
>an ABI type, "fmarch" and, conceivably, other scripts will have to know
>all the detailed processor types that support a particular ABI, and may
>thus have to change over time as new instructions are added to
>instruction sets and new processor types are added.

>Perhaps later SVR4.x releases have already done this, but if not:

>	There should be a new SI_ABI "command" for "sysinfo()", that
>	returns a string that indicates the ABI to which a system
>	conforms; for example, it would return "i386", or something such
>	as that, on 80386-based machines, 80486-based machines,
>	Am386-based machines, Cyrix-chip-based machines, Pentium-based
>	machines, etc..

Not done, but not a bad idea...
-- 
Mats Wichmann
Unisoft Corporation
mats@unisoft.com (or mats@netcom.com)

Silly Disclaimer:  speaking only for myself, except when I'm not.

Why whould a script care. The Generic ABI lists all the commands an
ABI conforming script may call. If a script is attempting to perform
different functions based on architecture type then by definition "sort of"
the script is non ABI conforming.

The goal of the ABI is one executable per architecture and in the case of
scripts, one script per generic ABI for all machines.

Now this doesn't address the real world problem of having servers
export a tree which contains binaries for a bunch of different machines,
but some view this as an admin problem not an ABI problem.

Andy

>Why whould a script care.

Because the script might be a wrapper script around an application -
let's give the application the hypothetical name "Frame Maker" - that
finds out the architecture for the machine, and runs the appropriate
binary, because the hypothetical vendor of this application - let's give
them the hypothetical name "Frame Technology" - apparently wants to have
shared versions of the non-architecture-dependent files, and separate
directories for the architecture-dependent files.

And yes, I *did* get bitten by that when I tried firing Frame up on a
Solaris 2.x machine here; the obvious fix, of using "uname -p", isn't
guaranteed to allow the same binary to be used on, for example,
386-based and 486-based boxes.

If you don't think Frame is doing the right thing, try convincing *them*
of that - and, if you don't succeed, consider that having "uname -b"
might be better than forcing Frame to have to recognize that "i80386"
and "i80486" and "iPentium" and... are really equivalent for its
purposes.

And also consider that Frame might not be the *only* application that
does this....

>The Generic ABI lists all the commands an
>ABI conforming script may call. If a script is attempting to perform
>different functions based on architecture type then by definition "sort of"
>the script is non ABI conforming.

So?  Who cares?  What's the *cost* of putting in a "get the architecture
name" option into "uname"?

>Now this doesn't address the real world problem of having servers
>export a tree which contains binaries for a bunch of different machines,
>but some view this as an admin problem not an ABI problem.

And some don't.