This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C11 threads ABI questions - enum values


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]