This is the mail archive of the
mailing list for the glibc project.
Re: Request for comments: reserving a value for O_SEARCH and O_EXEC
- From: Rich Felker <dalias at aerifal dot cx>
- To: Christoph Hellwig <hch at lst dot de>
- Cc: linux-api at vger dot kernel dot org, "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Tue, 6 Aug 2013 09:42:54 -0400
- Subject: Re: Request for comments: reserving a value for O_SEARCH and O_EXEC
- References: <20130805222544 dot GA19168 at brightrain dot aerifal dot cx> <20130806055425 dot GA9280 at lst dot de>
On Tue, Aug 06, 2013 at 07:54:25AM +0200, Christoph Hellwig wrote:
> On Mon, Aug 05, 2013 at 06:25:44PM -0400, Rich Felker wrote:
> > Hi,
> > [I'm resending this to linux-api instead of linux-kernel on the advice
> > of Joseph Myers on libc-alpha. Please see the link to the libc-alpha
> > thread at the bottom of this message for discussion that has already
> > taken place.]
> As told you earlier on linux-kernel just send a patch with your semantics
Apologies, I did not see the reply, and I'm still looking for it. I
should have put the request to CC me more prominently in the email...
> to lkml. We're not going to reserve a value for a namespace that is
> reserved for the kernel to implement something that should better
> be done in kernel space.
Did you mean "that should better be done in user space"?
Whether O_SEARCH and O_EXEC are provided fully natively by the kernel
or handled by userspace, either way a reserved value in the open flags
must be set aside. Otherwise any value used by the userspace
implementation would risk conflicting with future kernel features
using the same bit(s).
I fully understand that the kernel folks may not want to put O_SEARCH
and O_EXEC specific semantics in the kernel when O_PATH can, with some
trivial additional code in userspace, provide what's needed already.
This is why, at this time, I'm requesting a reserved value and not
trying to push code into the kernel.