Re: biarch cooperation.
It may be worth noting that the linux *kernel* has adopted the term
'subarchitecture' as well, to mean something different from that discussed
here. It might be worthwhile staying away from that particular term
unless we can adopt the kernel's definition. See
http://kniggit.net/wwol26.html
and search for 'subarchitecture'.
My best paraphrase of the kernel definition is for m68k, where 'amiga' and
'macintosh' are different _subarchitectures_ of the m68k _architecture_.
By this the kernel means they have the same processor but different buses,
devices, etc.
In contrast, all these "subarchitectures" of m68k would use the same abi.
I believe we were using "subarchitecture" to mean a grouping of compatible
abis, such { i386, i486, i585, i686 }, all of which are interoperable on a
machine with the i686 "architecture". Likewise { arm26, arm } are
interoperable -- to some extent, at least. You need to use a special call
instruction between arm26 and arm code, IIRC, but this is something
the dynamic linker _could_ do (i don't know if it does yet).
On the other hand (if I'm understanding the discussion properly) amd64 and
x86 are *not* "compatible abis". They are instead "incompatible abis
which can run under a single kernel". We should have a term
for this grouping. Substituting "architecture" for "kernel" in the
definition leads to confusion, let's avoid that for now.
Suggestions welcome for names!
I suggest the suboptimal-but-clarifying-for-now terms:
1) "arch" vs "architecture"
"arch" is the debian notion which distinguishes sparc/sparc64 and
mips/mips64. "architecture" has its own definition to computer
engineering types. Thus the "UltraSPARC architecture" can be
either the "sparc arch" or the "sparc64 arch", or maybe even both!
I used SPARC instead of MIPS here because it seems to
me like we actually want to use *three* "arch" types on MIPS,
one for o32, one for n32, and one for n64. The "architecture"
is still something like "MIPSIII". Which makes "arch" mean
something like "abi", in the end --- this constraint is due to the
fact that "arch" must distinguish debian packages in the archive.
2) "ABI-group" for groups of compatible ABIs, i.e. {i386, i486, i586}.
This might be called the "i586 ABI-group". (I said these terms
were suboptimal: suggest something which flows better yourself!)
Similarly, {arm, arm26} might be the "arm ABI-group".
3) "arch-group" for "incompatible *ABI-groups* which run under the
same kernel". For example, the "i686 ABI-group" and the "amd64
ABI-group" will both run under a suitable kernel on an amd64 machine.
The "amd64 ABI-group" contains only the single amd64 ABI.
Another "arch-group" might be {mips_o32, mips_n32, mips_n64}; each of
whose components is an ABI group with a single member.
I'm not happy with "arch" in the name "arch-group" here. Better
suggestions requested.
4) The "kernel architecture" is simply the "arch-group" which the
kernel supports. As pointed out previously, with clever kernel
emulation, this "arch-group" may have little to do with the
capabilities of the underlying hardware.
Does this sound reasonable?
"kernel architecture" = "collection of ABI groups" (arch-group)
"ABI groups" = "collection of compatible ABIs" (abi-group)
Now all we need are short catchy phrases for these that work well in a
debian control file!
--scott
atomic Panama Pakistan Yeltsin immediate Rule Psix Philadelphia Waihopai
Treasury corporate globalization General agent Cheney North Korea
( http://cscott.net/ )
Reply to: