From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ulrich Drepper <drepper@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
dhowells@redhat.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, hch@infradead.org,
viro@zeniv.linux.org.uk, adilger@sun.com,
alan@lxorguk.ukuu.org.uk, akpm@linux-foundation.org,
mtk.manpages@gmail.com
Subject: Re: [RFC PATCH] vfs: new open(2) flag to open filesystem node
Date: Mon, 6 Jul 2009 08:59:17 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0907060858560.3210@localhost.localdomain> (raw)
In-Reply-To: <a36005b50907052250n7a73a19r3ce674f08a402703@mail.gmail.com>
On Sun, 5 Jul 2009, Ulrich Drepper wrote:
> On Sun, Jul 5, 2009 at 17:40, Linus
> Torvalds<torvalds@linux-foundation.org> 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
prev parent reply other threads:[~2009-07-06 16:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-30 9:56 [RFC PATCH] vfs: new open(2) flag to open filesystem node Miklos Szeredi
2009-06-30 20:25 ` David Howells
2009-07-01 4:59 ` Miklos Szeredi
2009-07-05 19:35 ` Ulrich Drepper
2009-07-06 0:40 ` Linus Torvalds
2009-07-06 5:50 ` Ulrich Drepper
2009-07-06 12:29 ` Miklos Szeredi
2009-07-06 15:59 ` Linus Torvalds [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.01.0907060858560.3210@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=adilger@sun.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dhowells@redhat.com \
--cc=drepper@gmail.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mtk.manpages@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).