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

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
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!

atomic Panama Pakistan Yeltsin immediate Rule Psix Philadelphia Waihopai 
Treasury corporate globalization General agent Cheney North Korea 
                         ( http://cscott.net/ )

Reply to: