Re: biarch cooperation.
C. Scott Ananian wrote:
[snip]
> 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.
Debian-installer uses it the same way.
> 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).
"ABI variants" is probably a reasonable term for these. Small
differences, but at least upward compatible.
> 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.
I would say "Multi-ABI". The toolchain/libc developers use "Multilib"
for Multi-ABI libraries.
[big snip]
> Does this sound reasonable?
> "kernel architecture" = "collection of ABI groups" (arch-group)
This depends on the context, since the kernel _runs_ on an
(incarnation of an) architecture but _provides_ one or more
ABIs to the userland.
> "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!
AFAICS the control file needs only
Architecture: foo | bar
This is a bit of a misnomer, but it keeps things backward compatible.
Thiemo
Reply to: