This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH] Support HWCAPs for MIPS
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>, 'Andrew Pinski' <pinskia at gmail dot com>, "Rich Felker (dalias at libc dot org)" <dalias at libc dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "'macro at codesourcery dot com'" <macro at codesourcery dot com>
- Date: Wed, 15 Oct 2014 19:01:11 +0000
- Subject: RE: [PATCH] Support HWCAPs for MIPS
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320F271C0 at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1410142256280 dot 30087 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B0235320F27C65 at LEMAIL01 dot le dot imgtec dot org>
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