Re: ARMv4-support in armel/squeeze?
> On Thu, Dec 30, 2010 at 7:29 PM, Paul Brook <paul@codesourcery.com> wrote:
> >> you have to bear in mind that "future porting" *used* to be very
> >> uncommon an occurrence (as if doing it 14 times is "uncommon")
> >>
> >> but with the massive explosion in compiler options for ARM processors
> >> alone, the process of "porting" now becomes a massive headache.
> >
> > Really? AFAIK
>
> precisely. as far as you know. (and it also has to be said "as far
> as _any_ of us know")
>
> > the only really interesting option (soft vs. hard float ABI) has
> > already been done.
>
> interesting to whom? the point being: the moment you start dictating
> what is "interesting" then you automatically exclude a bunch of
> people. it doesn't _matter_ what options you choose and declare as
> "interesting": that _automatically_ excludes everybody else's
> (preferred) options.
s/interesting/relevant/ if it makes you happier.
My point is that there are a very small number of options that actually change
the ABI. All the rest, including different architecture levels, flavors of
VFP/NEON, ARM v.s. Thumb, etc. do not break binary compatibility, so can be
done within/on top of the existing ports. Out of all the options you may have
a preference on, very few require a new port.
> > I guess we might want a big-endian port eventually, but
>
> ok, yes. fantastic - there you go, you came up with an example. so
> you see, we can't guess the future, but despite that - no in fact
> because we cannot guess the future, it is ridiculous to make people
> such as martin and konstantinous (and then the next "future" person,
> and the next, and the next, and the next) work f*****g hard each and
> every time: it puts up a massive barrier and limits the possibilities
> for debian as a whole.
This is all based on the assumption that new ports are required with any
frequency. I have a hard time believing that is true.
I suspect you're seeing an artificial need because currently the only way to
create optimized builds for some CPU variant is a whole new port. In this
ccase you're effectively just rebuilding an existing port. The ABI is
unchanged, so using existing armel packages to satisfy dependencies while
bootstrapping should be trivial.
What you really want in this case is to provide optimized variants of the
packages you care about within the existing port. i.e. you're fixing the wrong
thing.
In principle I've no objection to being able to cross-build Debian from
scratch. However that's a major policy change from building native, and I
don't think "makes it easy to bootstrap the base system for a new port" is
sufficient justification.
In the specific example that started this conversation, an ARMv4 port can be
created by rebuilding the existing armel port without needing to start from
scratch. Obviously you'd need to be using armv4t or later buildds until that
was complete, but given how slow ARMv4 hardware is you'd want to do that
anyway.
> the only reason i got debian working on an S3C6410 9in laptop was
> because frans did the debian-installer port
I don't see how this is relevant. We're talking about *architecture* ports.
Installer and kernel/bootloader images for whatever random machine you happen
to have is a completely separate issue.
Paul
Reply to: