[PATCH] Support HWCAPs for MIPS

[Joseph S. Myers]

On Wed, 15 Oct 2014, Matthew Fortune wrote:

> For architecture independent interfaces/extensions I completely agree as it
> is not possible to predict what values will be assigned. In this case we
> have a spec which the kernel and glibc can follow for MIPS. I'm not sure I
> see the need to wait for the kernel changes to hit the main kernel repo.
> 
> I.e. if we had agreement on a spec between an architecture maintainer for
> the kernel and glibc then that would seem sufficient.

I don't think it's wise to assume that these particular values will be the 
first ones getting into the kernel, rather than someone else deciding to 
implement some other HWCAP values on MIPS and getting those in first (and 
thereby taking the first available values, which is the natural choice).  
Cf. cases where people have had out-of-tree patches for socket 
address/protocol families and have had to change the numbers assigned 
because of others going in the kernel and taking those values.

If the values get in the kernel quickly, there isn't much delay in glibc.  
If they take as long to get in the kernel as NaN2008 support (where more 
than a year after glibc support went in, glibc built for NaN2008 still 
uses arch_minimum_kernel=10.0.0 because the kernel support still hasn't 
gone in), that's a very long time to hope that no-one else gets in some 
other MIPS HWCAP values.

I've no idea if you can persuade kernel people of the merits of defining a 
value in a kernel header to fix the ABI even if the actual implementation 
follows later (cf. the O_* discussions, though I think the conclusion 
there ended up being that the kernel should implement the actual semantics 
rather than just reserving values for userspace implementation).

-- 
Joseph S. Myers
joseph@codesourcery.com