This is the mail archive of the
mailing list for the glibc project.
Re: Revisiting O_SEARCH and O_EXEC
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: <libc-alpha at sourceware dot org>
- Date: Sun, 4 Aug 2013 21:38:38 +0000
- Subject: Re: Revisiting O_SEARCH and O_EXEC
- References: <20130802173236 dot GA2491 at brightrain dot aerifal dot cx>
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