Date: Sat, 16 Mar 2019 10:12:20 -0400 (EDT)
From: Mouse <mo...@rodents-montreal.org>
Message-ID: <201903161412.kaa07...@stone.rodents-montreal.org>
| That borders on meaningless. If Ultrix never ran on SPARC or x86_64
| (which was the case AFAIK), what would it even mean to be compatible
| with it?
It doesn't mean anything - that's not the point. The point is that
these compat options are retained because people have old binaries
which use them (on the appropriate architecture). But those systems
are somewhat rare (and often slow) and aren't the best place to test
anything - especially since if an old binary hasn't triggered a particular
bug in the past, it is unlikely to in the future either.
But while that is why we have the compat stuff - all of that is just
software, and subject to all of the issues of any other software, and
can be used in any environment whatever. Just because we'd have no
reason to ever change to a different ABI just for the fun of it, doesn't
mean that we cannot (we shouldn't. but we could). That's what these
emulation compat layers are - they simply map the other system's ABI
into ours. There's no particular reason (except that we have chosen
differently) that we could not have ABIs in all of our systems that are
compatible with ULTRIX, or OSF1, or SunOS, or even SysVR4 (or R3. or
even Sustem III). Some of the low level details might differ, but
not all that many, from architecture to architecture, but most of the
code will run anywhere. We don't do that because it's point;ess in
general ... but for testing that it still works it need not be.
No-one wants to run ultrix binaries on a sparc or PC, but we can use
those systems to test the code that would normally only run on a vax
or pmax. It is all just code after all.
kre
