Re: Revisiting O_SEARCH and O_EXEC

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 2 Aug 2013, Rich Felker wrote:

> Another option, which I like better, is defining both O_EXEC and
> O_SEARCH to 3. This makes them look more like access modes, as they
> should, and avoids the need to change the definition of O_ACCMODE.
> However, I think this option would require agreement from the kernel
> folks, since it would be big trouble if they later wanted to use this
> value for something else. On the plus side, using the value of 3 would
> allow the kernel folks to explicitly support O_SEARCH and O_EXEC
> semantics kernel-side in the future, without help from the userspace
> library functions.

*Whatever* the option I think it should be coordinated with the kernel in 
the first place.

More generally: we should do better on kernel coordination for things 
where it may not be clear where responsibility for implementing particular 
semantics lies; there should be somewhere tracking known POSIX issues in 
the (glibc, Linux) combination where it's not clear that glibc alone is 
responsible for the issue (if glibc alone is responsible, we have glibc 
Bugzilla for that); more use should be made of the linux-api mailing list 
which is meant to be the appropriate place for such discussions of the 
kernel/userspace interface.  We've improved coordination with GCC, but 
still need to work more on coordination with Linux.

-- 
Joseph S. Myers
joseph@codesourcery.com