Re: subarch support
On Fri, Jul 16, 2010 at 4:11 AM, Riku Voipio <riku.voipio@iki.fi> wrote:
> On Tue, Jul 13, 2010 at 03:24:35PM +0200, Loïc Minier wrote:
>> On Tue, Jul 13, 2010, Riku Voipio wrote:
>> > If dpkg had subarchitecture support, lpia wouldn't have been as big
>> > a issue. Ubuntu decided to shortcut and not add support for compatible
>> > subarchs in dpkg, and the result was what it always is when people make
>> > shortcuts...
>> >
>> > Subarchs could also be useful if we wanted to build softfp abi compatible
>> > armv6/armv7 armel builds of the whole debian repository. Of course we could do
>> > builds without subarchs, but then users would be unable distinguish which
>> > installed packages are for which cpu, and providing that via debian infra
>> > would not be possible.
>
>> It sounds like you have good ideas about the subarch concept; would you
>> mind expanding on them a bit?
>
> Basicly close to what RPM does, so it is not my idea :) For example:
>
> On X86 one could have i486, i586, i686, atom, core2 - all being subarchs of
> i386 and crossinstallable.
>
> On ARM one could have armelv5, armelv6, armelv7, armelv7neon, .., all subarchs
> armel and crossinstallable. Before someone jumps "what about a ARMv6 with NEON but
> no VFP", obviously some discretion must be used when selecting subarchs to be
> supported.
I don't think NEON without VFP is even possible :D
> At package install time, package manager knows on what cpu we are running on,
> and can thus select which subarchs are supported. For example a ARMv6 machine
> could install armel.deb, armelv5.deb, armelv6.deb packages.
Why wouldn't it just install armelv6.deb package alone? Why have the rest of it?
> This way ubuntu wouldn't have just had to drop armv5 support when building armv6
> stuff, or make it impossible for lpia users to install i386 .debs.
I don't think Ubuntu cares to install full desktop systems or servers
on armv4 systems with 64MB RAM - their choice is valid for the
platforms their OEMs (and basically anyone who wants to install
Ubuntu..).
A dedicated port for armv7 with VFP is all we're looking for here.
I've been down this road before in discussions with distro builders -
and even experienced it with more bleeding edge stuff like
OpenEmbedded - there is always some clever technological solution
proposed on a wiki, but it takes years to complete. In the meantime
nobody is benefiting from it, and in the end, it turns out nobody is
benefiting from it.
Can we just concentrate on a port which is armv7-a+vfpv3-d16
(potentially with thumb2 like Ubuntu, if only because Ubuntu did it
and one of the spurs for this is we want Debian and Ubuntu to be on
the same page with regards to processor support. Ubuntu has the
ability to convince people like Adobe that this is a mainstream,
OEM-focussed effort. Debian, however, is the core..
Ubuntu are already halfway to doing it for Lucid, but we know the mess
from lpia, we know the difficulties of backporting (I can already see
in my mind a thousand bugreports going WONTFIX because of the
differences) and we just want to best support the forward-looking
improvement of ARM processors with the most reasonable performance
optimizations enabled. armv4t and software emulation of floating point
is just not the best way to build applications for the most modern
architecture and going forward.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
Reply to: