[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140708121229.GA21107@infradead.org>
Date: Tue, 8 Jul 2014 05:12:29 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Steven Stewart-Gallus <sstewartgallus00@...angara.bc.ca>
Cc: linux-kernel@...r.kernel.org,
Jeff Layton <jlayton@...chiereds.net>,
"J. Bruce Fields" <bfields@...ldses.org>,
linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
Andy Lutomirski <luto@...capital.net>,
linux-man@...r.kernel.org
Subject: Re: [PATCH 1/1] include/uapi: Define AT_FDNODIR constant as future
guarantee
On Sat, Jul 05, 2014 at 07:51:19PM +0000, Steven Stewart-Gallus wrote:
> From: Steven Stewart-Gallus <sstewartgallus00@...angara.bc.ca
>
> This constant means that in the far future it might be possible to
> define other AT_FD* constants.
>
> Signed-off-by: Steven Stewart-Gallus <sstewartgallus00@...angara.bc.ca>
> ---
>
> This is my first kernel patch but this is really trivial so I hope I'm doing
> this right.
Almost. For one you really should explain what the flag does,
especially if it's not actually use.
It took me a while that you're trying to document the way Linux
currently behaves for the cases where the dfd argument to the various
*at is neither a valid file descriptor nor the magic AT_FDCWD constant.
Posix says that openat with an absolute path is equivalent to open, so
the only strictly allowed other flags would those that allow some form
of relative path, but treat it differently than the currently possible
options. I can't really think of a good way to do that, although we
recently had a case where a different AT_* value would be useful, even
if not fully conforming to that Posix wording.
Your explanation of what this constant does should also go into the man
page, so in addition to the kernel patch you should also propose a patch
to the man page documenting it.
Also I don't think AT_FDNODIR is a good choice of name, AT_ABSOLUTE
would be a lot more descriptive.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists