This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc and linux-man disagrees about pkey_alloc
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, mtk dot manpages at gmail dot com, nd at arm dot com, linux-man at vger dot kernel dot org, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 16 May 2018 11:18:44 -0400
- Subject: Re: glibc and linux-man disagrees about pkey_alloc
- References: <adae131e-c782-9508-808f-9cbea92ef694@arm.com> <1f2551f3-3d6d-3905-433e-967af2c3be87@redhat.com>
On Wed, May 16, 2018 at 04:36:03PM +0200, Florian Weimer wrote:
> On 05/16/2018 01:10 PM, Szabolcs Nagy wrote:
> >glibc sysdeps/unix/sysv/linux/bits/mman-shared.h:
> >
> >int pkey_alloc (unsigned int __flags, unsigned int
> >__access_rights) __THROW;
> >
> >linux-man http://man7.org/linux/man-pages/man2/pkey_alloc.2.html :
> >
> >int pkey_alloc(unsigned long flags, unsigned long access_rights);
> >
> >i assume the documentation should be fixed (as the glibc
> >code is already in use)
>
> unsigned long on the kernel side is unsigned long long in userspace
> for the x32 variant of x86-64, so the kernel types aren't that
> helpful for describing the user-space interface in an
> architecture-independent fashion. I expect the flags to be
> consistent across architectures, so there can only be 32 of them
> anyway, and access rights currently use two bits on x86 (and three
> on POWER, I think).
There's possibly some argument to be made that by the time 32 bits are
filled, 32-bit archs will be legacy-only and won't be getting new pkey
hardware features, in which case having the full 64 bits available
would be nice... But I don't really care what decision is made as long
as it's consistent.
Rich