This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Request for comments: reserving a value for O_SEARCH and O_EXEC

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]