This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH] Support HWCAPs for MIPS
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: "Joseph S. Myers" <joseph at codesourcery 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 18:20:21 +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>
Joseph S. Myers <joseph@codesourcery.com> writes
> On Tue, 14 Oct 2014, Matthew Fortune wrote:
>
> > +#define HWCAP_MIPS_R6 0x00000001
> > +#define HWCAP_MIPS_MSA 0x00000002
>
> HWCAP values are assigned by the kernel; they are not ELF-level interfaces
> but interfaces between the kernel and userspace; we normally add new
> values once there's been a kernel.org release with those values in, as
> part of the routine review of new kernel releases for any new interfaces
> of relevance to glibc. In this case, I don't see these values in
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.
> Being Linux-specific, I think the right location for these files is
> sysdeps/unix/sysv/linux/mips/ similar to ARM (although other architectures
> putting such OS-specific definitions in OS-independent files doesn't cause
> practical problems in the absence of other-OS ports for those
> architectures).
OK.
> If you want to get other patches depending on HWCAP tests in some way into
> glibc before the HWCAP values are allocated in the kernel, I advise
> setting up the glibc code to hardcode whatever it would do with an old
> kernel that never sets a nonzero HWCAP, and then adding support for
> handling new kernel features later when the values are allocated.
Given the current approach is to wait for changes to hit the kernel I'll
skip this for now and hard-code as suggested.
Thanks,
Matthew