This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: C11 threads ABI questions - enum values
- From: Rich Felker <dalias at libc dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Fri, 3 Oct 2014 11:32:48 -0400
- Subject: Re: C11 threads ABI questions - enum values
- Authentication-results: sourceware.org; auth=none
- References: <20140818192714 dot GS12888 at brightrain dot aerifal dot cx> <20141001211308 dot 88F742C397E at topped-with-meat dot com> <20141001211606 dot GN23797 at brightrain dot aerifal dot cx> <20141001213022 dot 798942C3AAD at topped-with-meat dot com> <20141002001720 dot GO23797 at brightrain dot aerifal dot cx> <20141002214229 dot 734B62C3A2F at topped-with-meat dot com> <20141002222958 dot GR23797 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1410031038300 dot 26280 at digraph dot polyomino dot org dot uk> <20141003151917 dot GS23797 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1410031527460 dot 14538 at digraph dot polyomino dot org dot uk>
On Fri, Oct 03, 2014 at 03:31:14PM +0000, Joseph S. Myers wrote:
> On Fri, 3 Oct 2014, Rich Felker wrote:
>
> > The kernel position is that O_SEARCH and O_EXEC can be done by
> > userspace in terms of O_PATH, but I'm not sure that's correct. There's
>
> Looking back at the linux-api discussion from Aug 2013, I don't see that;
> it seems to have tailed off without a conclusion but with at least some
> suggestions that these features should be implemented in the kernel.
>
> > an old thread (I think libc-alpha was CC'd on it but I'm not sure)
> > about that. O_TTY_INIT could probably be done in userspace too and
> > that might be what they expect us to do for it, too...
>
> In both cases, even if things are to be implemented in userspace, the
> values need reserving in the kernel to ensure there aren't cases where the
> kernel is providing useful semantics for some value that aren't readily
> accessible from userspace because that value is used in libc for something
> else.
Indeed, they need to be reserved on the kernel side, and during the
discussion on linux-api, almost everybody seemed to be failing to
understand why this is needed... :(
Rich