Followup on ARM Minisummit at 2011 LPC

[Jon Masters]

On Fri, 2011-10-07 at 00:40 +0200, Alexander Graf wrote:
> Am 06.10.2011 um 22:29 schrieb Paulo César Pereira de Andrade <paulo.cesar.pereira.de.andrade at gmail.com>:
> 
> > Em 6 de outubro de 2011 15:41, Jon Masters <jcm at redhat.com> escreveu:
> >> On Thu, 2011-10-06 at 15:20 -0300, Paulo César Pereira de Andrade wrote:
> >>> Em 6 de outubro de 2011 14:38, Jon Masters <jcm at redhat.com> escreveu:
> >>>> On Tue, 2011-10-04 at 00:41 -0300, Paulo César Pereira de Andrade wrote:
> >>>> 
> >>>>> For now I have been only considering gcc as compiler
> >>>> 
> >>>> I think, realistically, so have we. But I'm open to rethinking that.
> >>> 
> >>>   The problem is that this compiler apparently only offers two options,
> >>> softfp (not softfp calling convention) by generating code without fpu
> >>> support, and hardfp that only supports float arguments on float
> >>> registers. IMO, the hardfp abi is not something for a distribution,
> >>> but for a "closed" (not necessarily closed source) image, where
> >>> the exact hardware is known before hand, and from Linux pretty
> >>> much only the kernel and a few packages are used.
> >> 
> >> Yup. We disagree :)
> >> 
> >> I believe incompatible ABI changes are painful, but occasionally (very
> >> occasionally, and with some planning, co-ordination, justification, and
> >> a planned execution) can be necessary. The hard float ABI brings enough
> >> benefits that the various distributions are standardizing on it for v7.
> >> I would hope that we can all get behind this and treat v7 as a new
> >> architecture rather than simply an iteration, but I understand if you
> >> don't want to do that. Having said that, we do want to do that :)
> > 
> >  I understand that the arm ecosystem is not like x86; imagine if
> > suddenly distros did choose to use regparm=n, sseregparm=n,
> > well most distros already expect i686/sse, but do not use sse
> > due to abi constraints.

It's important to also realize that general purpose ARM systems are a
new area, and so we have an opportunity to make some changes. Nobody is
going to change the x64 ABI (ok, so x32, but it's not going to be widely
adopted by many for this exact reason) because it's so well established
with end users. Conversely, at least in the case of Fedora, there is
still an opportunity to fix a lot of things while our main user base is
very technically inclined and willing to adapt. In the case of
Canonical, and others thus far, a lot of vertical integration is
happening and so there is still opportunity to shift future systems even
in those cases because existing users will stay on older software bases.

In the end there will be many more things we don't like, but hopefully
it will be a few decades before we get to that point. I'm all for
standards and not throwing things away - once we get to that critical
mass beyond which it doesn't make sense to start things over - but I
don't think we've reached that point and I want to clean up now :)

> However, nobody compiles x86 binaries without tls support or for
> < i586 today anymore either. Armv7 seems like a nice time for a clean cut.

Exactly. We've done things like that before in x86. Of course it's a
little different when no existing software runs afterward (except in the
case that you have multi-arch, which I'll mention as a kudos to Debian
and friends for doing there). So the x86 equivalent would be more like
promoting x32 for widespread use, which would not make sense if we were
at a similar level of general purpose adoption in the ARM ecosystem.

> >  I think the point here is the "bring enough benefits" that we
> > are not agreeing. Personally, what I am afraid is that who will
> > decide this is not distros, but companies providing binary
> > blobs (e.g. video drivers).
> 
> There are two pieces to the puzzle here:
> 
> 1) binary video drivers
> 
> I don't want them. If you really have to support companies that don't
> want to work with us in reasonable ways, just put your X server in a
> chroot for whatever abi/environment they want and call it a day

I want to be a bit more pragmatic than that :) However, I think since
we're mostly moving to the same ARMv7 base with the same ABI, we have
enough mass that there will be new drivers built for the userspace.

> 2) binary application software
> 
> Right now there is none. Period. Maybe ARM will get enough market
> share one day to get ISVs to actually develop for ARM. By then they
> will check what distros use abi-wise and go with that.

Indeed. I think we will get there, which is why I want to fix things now
so that we only have to live with whatever kludges and hacks are
developed years from now after it's too late ;) We can at least do
cross-distro standards, get LSB rolling, things of that nature.

> If that's hardfp then it's hardfp and everyone's happy.

Right. I think one thing we agreed at LPC is that enough of us agree on
hardfp that we've got momentum there. Others are free to disagree and go
their own way. I'd like it if we'd continue to build consensus as a
community around the need to standardize, so that the next time there
are big decisions to make even more of us can agree :)

Jon.