[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: biarch cooperation.

C. Scott Ananian wrote:
> 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.


Reply to: