C11 threads ABI questions - enum values
Christoph Hellwig
hch@lst.de
Sat Oct 4 17:53:00 GMT 2014
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.
More information about the Libc-alpha
mailing list