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: Christoph Hellwig <hch at lst dot de>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, libc-alpha at sourceware dot org
- Date: Mon, 5 Aug 2013 10:19:47 +0200
- 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>
On Sun, Aug 04, 2013 at 09:38:38PM +0000, Joseph S. Myers wrote:
> 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.
*nod*
I can't see any reason why implementing these two modes in libc would be
preferable over doing it in the kernel. I could think of many reasons why it
would be a bad idea.
Rich, given that you're obviously interested in implementing this feature,
how about you try to send patches implemnenting it in the kernel?