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

[Lennert Buytenhek]

On Thu, Jan 03, 2008 at 11:01:46AM -0600, Mark Hatle 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.

Yeah, that's correct.  It's not one of the feature letters.


> 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.

I've considered that, but that breaks configure scripts that match
against arm*b-* to determine whether the target is big-endian or not.

Using the 'v' is a bit of a hack, but I can't come up with anything
better.


> > (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.

I had a quick look at glibc, but I don't see any place where it makes
the info available.  If you have this working, I'd be interested.


> > 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.

I don't understand that last sentence -- how does the approach I
proposed not allow having an in-kernel VFP emulator set HWCAP_VFP?


> 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.)

My main interest is in Fedora, and I'd like the Fedora/ARM distro to
stay as close to upstream Fedora as possible, so if this requires rpm5
(as it seems to), it won't work for me unless Fedora switches to rpm5
(which seems somewhat unlikely :-) or ports that feature over.