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: Christoph Hellwig <hch at lst dot de>
- To: Rich Felker <dalias at libc dot org>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Sat, 4 Oct 2014 19:53:46 +0200
- Subject: Re: C11 threads ABI questions - enum values
- Authentication-results: sourceware.org; auth=none
- References: <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> <20141003153248 dot GT23797 at brightrain dot aerifal dot cx> <20141003183910 dot GA8806 at lst dot de> <20141003194932 dot GU23797 at brightrain dot aerifal dot cx>
On Fri, Oct 03, 2014 at 03:49:32PM -0400, Rich Felker wrote:
> On Fri, Oct 03, 2014 at 08:39:10PM +0200, Christoph Hellwig wrote:
> > On Fri, Oct 03, 2014 at 11:32:48AM -0400, Rich Felker wrote:
> > > 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... :(
> >
> > At least of O_SEARCH and O_EXEC I strongly disagreed with the idea that
> > they should be implementated in userspace and still do.
>
> I do to, but for now it's the only way possible on Linux.
The other way would be to send patches, which I tried to encourage
you to do a few times. It basically boils down to:
- allow a few more operations on O_PATH fds, as listed by Posix
for O_SEARCH and O_EXEC
- add two defines that alias O_SEARCH and O_EXEC to (O_PATH|3),
and..
> For instance
> it seems to be impossible to implement the POSIX rule (at least as I
> understand it) that, when using an O_SEARCH or O_EXEC fd, the status
> of the +x mode bit at open-time, rather than at the time of the
> operation, dictates success or failure. There are a few other corner
> cases where you want O_PATH and O_SEARCH/O_EXEC to behave differently,
> too: for example, O_PATH|O_NOFOLLOW should open the symlink, while
> O_SEARCH|O_NOFOLLOW or O_EXEC|O_NOFOLLOW should fail if the target is
> a symlink.
implement these quirks keyed off the (O_PATH|3) flag.