Re: [RFC PATCH] vfs: new open(2) flag to open filesystem node

From: Linus Torvalds
Date: Mon Jul 06 2009 - 12:00:26 EST




On Sun, 5 Jul 2009, Ulrich Drepper wrote:

> On Sun, Jul 5, 2009 at 17:40, Linus
> Torvalds<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > O_SEARCH is only meaningful for directories. For anything else, it's not
> > at all POSIX - it's expressly defined to be "undefined".
>
> And this is why there is the differentiation with O_EXEC. Yes, i
> didn't mention it in the last email. But I mentioned it when it came
> up the first time.
>
> I don't say this is indeed what is wanted/needed here. But there are
> IMO some similarities and I think implementing O_SEARCH and O_EXEC is
> desirable. If it means completely different implementations from te
> proposed O_NODE, so be it. But my gut tells me there is some overlay.

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.

Put another way: it's better to start with something that is well-defined
(for us), and then say "in the special case of directories, this becomes
the same thing as O_SEARCH", than start with something that is defined
only for directories, and then say "ok, the behavior for other things is
undefined, so we could hijack it for our own uses".

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/