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: Christoph Hellwig <hch at lst dot de>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Christoph Hellwig <hch at lst dot de>, 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 16:03:21 +0200
- 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> <20130806134254 dot GT221 at brightrain dot aerifal dot cx>
On Tue, Aug 06, 2013 at 09:42:54AM -0400, Rich Felker wrote:
> > 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...
Sorry, it actually was libc-alpha that I replied to. I didn't notice
you sent two slightly different messages instead of a having a cross-posted
discussion, which would have been more useful.
> > 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"?
No. It should be done in kernelspace, just like all other O_ flags.
> 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).
No flag is going to get reserved without a proper (kernel-level)