This is the mail archive of the
libc-alpha@sourceware.org
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: Christoph Hellwig <hch at lst dot de>, <libc-alpha at sourceware dot org>
- Date: Mon, 5 Aug 2013 17:19:01 +0000
- Subject: Re: Revisiting O_SEARCH and O_EXEC
- References: <20130802173236 dot GA2491 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1308042134580 dot 25359 at digraph dot polyomino dot org dot uk> <20130805081947 dot GA5797 at lst dot de> <20130805121139 dot GE221 at brightrain dot aerifal dot cx>
On Mon, 5 Aug 2013, Rich Felker wrote:
> The kernel folks position from the beginning (see the early threads
> where O_PATH was added) seems to be that they think they've provided
> enough for O_SEARCH and O_EXEC and that they don't want to design to
> POSIX but instead design something that's general enough to provide
> what POSIX requires. I think this is misguided, but I don't want to
The O_* flags occupy a space shared by userspace and the kernel. If we're
to use flags in any way that is not a simple pass-through (which does seem
like an unfortunate complication where otherwise functions could just be
implemented through syscalls.list), then coordination with the kernel is
needed to avoid any future cases where flag values used with libc
functions become meaningful with the corresponding kernel syscalls, but
with different semantics.
> have that argument. In any case, adding it to the kernel only is
> useless because userspace won't be able to provide it until everybody
> has switched to Linux 3.11+. That'll be 10+ years. Userspace must
> provide it with what we have to work with as long as Linux 2.6 is
> relevant (supported by the libc).
It's perfectly reasonable for some libc features to depend on appropriate
kernel support, although certainly it's desirable to support them as far
as possible on older kernels (e.g. through fallback code emulating using
O_PATH).
> FYI, having the macros in fcntl.h but non-working breaks packages
> including coreutils.
It's not clear glibc should try to do any better than the kernel regarding
graceful failure modes in the absence of kernel support (that is, for
glibc to try to give accurate ENOSYS or similar errors when the kernel
support needed for the proper semantics of a given O_* flag isn't present,
when the kernel practice is to ignore unknown flags, and in general the
user may wish to pass through values unknown to glibc when their kernel is
newer than their glibc). Universal practice in glibc is that header
values are defined and functions declared for features in the newest
kernels even though the kernel in use at runtime may not support them.
--
Joseph S. Myers
joseph@codesourcery.com