[fedora-arm] Re: [PATCH, RFC] arm: add support for VFP architectures

[Mark Hatle]

Lennert Buytenhek wrote:
> (please CC on replies, I'm not on rpm-maint@)
> 
> The attached patch adds a 'v' near the end of the machine name if
> the (ARM) system we're running on supports VFP.  This allows building
> and using VFP-optimised RPM packages for ARM systems that have a VFP
> floating point unit.  
> 
> So e.g. glibc-2.7-2.armv5tel.rpm is the regular (softfloat) glibc that
> we have now, and glibc-2.7-2.armv5tevl.rpm would then be a glibc built
> to use VFP instructions, installable only on systems that have HWCAP_VFP.

As far as I was aware there wasn't a standard naming convention for VFP
in the arm cpu name.  So I'm a bit concerned that adding "...evl" (or
...evb) is going to be confusing in the name.

What we have done is called it armv5el_vfp.

> The idea behind this is that we want to support multiple different
> flavors of the Fedora/ARM port.  Right now we have just an armv5tel
> softfloat flavor, but we'll probably end up with a VFP flavor soon,
> and later on perhaps also an ARMv6 flavor, maybe a pure Thumb2 flavor
> at some point, etc.

Thumb2 at least has a naming convention so that should be easy to do..
(armv6t2el).

> (I would really like not to have to parse /proc/cpuinfo, but I don't
> see how to get at _dl_hwcap or AT_HWCAP -- as far as I see, ld.so uses
> this info to determine its library search path but doesn't export the
> info.)

The HWCAP stuff in in the aux vector of course.  I found a reference to
reading it from /proc/self/auxv, but I swear there is another way to
read this information w/o having to open any files.

Another reference I found was using DL_FIND_ARG_COMPONENTS macro.  But I
don't really know anything about it.  It's possible that the aux table
might be optimized away.

> Ideas?

An alternative suggestion.  Instead of changing the name or the arch,
would it make sense to use HWCAP settings as a run-time dependency.
This would allow in-kernel VFP emulation (if there ever was a such a
thing implemented) to set the capability and run/install the code as
appropriate.  RPM5 has a notion of run-time hardware capabilities and
that is probably the way this is going to be implemented there.  (They
are close to release, so it won't be in the first version of RPM5.. but
I do suspect the aux vector AT_HWCAP will be used on at least PPC in
future version.)

--Mark

> 
> Signed-off-by: Lennert Buytenhek <buytenh at marvell.com>