Date: Fri, 22 Feb 2013 22:58:18 -0500 From: KOSAKI Motohiro <kosaki.motohiro@...il.com> To: Rich Felker <dalias@...ifal.cx> Cc: libc-alpha <libc-alpha@...rceware.org>, musl@...ts.openwall.com Subject: Re: O_EXEC and O_SEARCH On Fri, Feb 22, 2013 at 10:17 PM, Rich Felker <dalias@...ifal.cx> wrote: > On Fri, Feb 22, 2013 at 10:05:03PM -0500, KOSAKI Motohiro wrote: >> > I'd like to have a conversation with the glibc team about O_EXEC and >> > O_SEARCH in the interest of hopefully developing a unified plan for >> > supporting them on Linux. Presumably the reason glibc still does not >> > have them is that Linux O_PATH does not exactly match their semantics >> > in some cases, and O_PATH is sufficiently broken on many kernel >> > versions to make offering it problematic. In particular, current >> > coreutils break badly on most kernel versions around 2.6.39-3.6 or so >> > if O_SEARCH and O_EXEC are defined as O_PATH. >> >> I'm curious why don't you implement them in kernel directly? > > See this thread for Linus's opinion on why O_SEARCH was not added: > > http://comments.gmane.org/gmane.linux.file-systems/33611 > > O_NODE seems to have been renamed to O_PATH, or perhaps O_PATH was a > later independent implementation of the same idea; it's not clear to > me which happened. But the idea is that the kernel folks did not want > to do O_SEARCH and O_EXEC properly in kernelspace but instead wanted > to provide a more general flag that could be used to implement both > O_SEARCH and O_EXEC. Do you mean following response? >I suspect that what we _could_ possibly do is to have something like >O_NODE, and after that - if the semantics (for directories) match what >O_SEARCH/O_EXEC wants, we could just do > >#define O_SEARCH O_NODE > >but my point is that we should _not_ start from O_SEARCH and make that the >"core" part, since its semantics are badly defined (undefined) to begin >with. I so, I don't think "start" mean refusing at all. However, I agree kernel folks dislike to hear "because it's posix". As far as no concrete good use case, any proposal may be going to be get negative response. However, if O_SEARCH is really useful, I think in kernel implementation is better because all other flags are implemented in kernel and it may prevent to create ugly corner case.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.