Re: biarch cooperation.
Goswin von Brederlow wrote:
[snip]
> > > I worked on dpkg the last days and I modified it to allow packages
> > > with the same name but different arch. Making the update transparent
> > > and backward compatible needs some more work but overall it seems to
> > > be working.
> >
> > First of all, I'd prefer "Multi-ABI" over "bi-arch" as the name
> > of this beast, because
> >
> > a) There may be more than two ABIs to support.
> > b) It is an ABI thing, at least MIPS can run three different
> > ABIs on many commonly used CPUs, which share the same Architecture.
>
> Its also an arch thing. i386/486/586/686 all use ia32 abi (i386 with
> i486 emulation). apt/dpkg should upgrade to a more optmized arch when
> a package becomes available too.
>
> For amd64 its muti-arch / multi-abi.
AFAICS this boils down to different ABIs. Even an i686 could be
multi-ABI in order to use its additional opcodes. Actually, it is
for packages like ssl (but uses a special solution for that).
[snip]
> > > The idea is as wollows: (names made to fit mips but I'm on amd64)
> > >
> > > - autoconf defaults to lib, lib32, lib64 depending on the host/target
> > > used
> >
> > This won't work well for MIPS. Targets are mips*-*-linux* and
> > mips64*-*-linux*, the latter will usually support all three ABIs.
>
> Something would be default for each. For mips that probably /lib, for
> amd64 its /lib64.
64 bit capable MIPS wants N32 most of the time, that is /lib32.
[snip]
> > > - dpkg-gencontrol (will) set "Architecture: mips | mips32 | mips64"
> >
> > Let this better refer to the ABI, like mips or mips_o32, mips_n32, mips_n64.
> > There is already too much confusion around the different mips* names:
>
> Architecture describes the hardware you need to run this.
But the hardware is abstracted away by the kernel. The kernel provides
an ABI to the userland. So you need a means of identifying an ABI, not
the class of silicon in the machine.
> Am I right
> that mips_o32 works on 32 bit mips and the others need a 64bit mips?
That's right.
> The packages would end up in different binary-<arch> ordners and apt
> would use the once the current hardware can run and mix them freely s
> long as abi restrictions allow.
Again, this depends on the ABI allowed by the kernel, not the
hardware. Point in case: Many of the mips{,el} machines currently
supported by debian are 64 bit capable, but no official debian kernel
allows to use more than 32 bit.
> > - MIPS I, MIPS II, ... MIPS 64R2 in uppercase refer to the ISA
> > (Instruction Set Architecture). The 64 bit capable ISA's are MIPS III,
> > MIPS IV MIPS64, MIPS 64R2. The non-64 bit capable ISA's are MIPS I,
> > MIPS II, MIPS 32, MIPS 32R2.
> > - mips64 refers to some 64 bit aspect, depending on the context, e.g.
> > mips64-linux is the GNU target for a toolchain which supports all
> > three ABI's mentioned above.
> > - ABI N32 runs only on 64 bit capable architectures, mips32 would be
> > a gross misnomer.
>
> You have to sort out what you call arch and what abi.
I referred above to the terms which are currently in use in the MIPS
world. Architecture is used a bit differently, but ABI should refer
to the same thing as in debian.
> I sugget only
> splitting arch for things that need different hardware, i.e. 32 bit
> and 64bit capable mips.
Well, given enough in-kernel emulation, nothing needs different hardware. :-)
The ABIs allowed by the kernel are the interesting thing, and we'll have
three for 64 bit MIPS. I don't know how well this fits with your idea of
an architecture.
[snip]
> > Again, ABI is IMHO a better term. "Subarch" usually describes different
> > machine architectures sharing same/similiar CPUs.
>
> Its coined by the iX86 + amd64 series. Might not translate well to
> other archs. But Abi doesn't quite cover it either.
Why not? E.g. the allowed opcodes are part of the ABI definition.
[snip]
> > It's probably best to use -mabi=n32 on a "MIPS64" system as default,
> > with exceptions for libraries, which should provide all three ABI
> > variants somehow, and exceptions for (very) large applications, which
> > are of little use in a 32 bit address space (and thus need -mabi=64).
>
> The problem with not using the arch to reflect those is that the
> debian archive allows only one version per architecture. You would
> have to name the packages differently which we want to avoid.
>
> If you want to have all three abis installable seperately you would
> need three archs.
Ok. In other words, debian uses a 1:1 mapping between its definition
of an architecture and the ABI (modulo kernels and optimizations for
some libraries). For 64 bit MIPS this means
Architecture: mips | mips_n32 | mips_n64
Architecture: mipsel | mipsel_n32 | mipsel_n64
with an order of preference *_n64 -> *_n32 -> *
and *_n64 only available for selected packages.
The underscore is probably unsuitable here, which characters are allowed?
Thiemo
Reply to: