From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
Eric Biggers <ebiggers@kernel.org>,
linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-integrity@vger.kernel.org, linux-ext4@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Victor Hsieh <victorhsieh@google.com>
Subject: Re: [f2fs-dev] [PATCH v2 01/12] fs-verity: add a documentation file
Date: Fri, 21 Dec 2018 10:47:14 -0500 [thread overview]
Message-ID: <20181221154714.GA26547@mit.edu> (raw)
In-Reply-To: <20181221070447.GA21687@infradead.org>
On Thu, Dec 20, 2018 at 11:04:47PM -0800, Christoph Hellwig wrote:
> Ted, I think you know yourself this isn't true. Whenever we added
> useful interface to one of the major file systems we had other pick
> it up, and that is a good thing because the last thing we need is
> fragmentation of interfaces. And even if that wasn't the case I don't
> think we should take short cuts, because even if an interface was just
> for a file system or two it still needs to be properly desgined.
This is why I think the interface argument is totally bogus.
If you're OK with Darrick's suggested interface, where you pass in a
file descriptor, offset and length --- that's just a superset of the
current interface, except where the file descriptor is in the file
which is going to be protected using fs-verity. So there's if you're
OK with that interface, we can add that interface later, and it's
really no big deal; it certainly doesn't add any extra complexity for
XFS --- assuming that XFS even gets around to adding support for
fs-verity.
Adding that extra complexity is not necessary for the current users of
the interface, and as I've said multiple times before, there's no
*value* in allowing the Merkle tree to be passed in via some arbitrary
file descriptor, which might even be on a separate fhile system, as
opposed in the file which is about to be protected using fs-verity.
Linus --- we're going round and round, and I don't think this is
really a technical dispute at this point, but rather an aesthetics
one. Will you be willing to accept my pull request for a feature
which is being shippped on millions of Android phones, has been out
for review for months, and for which, if we *really* need to add
uselessly complicated interface later, we can do that? It's always
been the case for internal Kernel interfaces not to add code "just in
case" it's useful, but rather when a user turns up. I argue we should
be doing the same thing for user-space visible interfaces.
Regards,
- Ted
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Dave Chinner <david@fromorbit.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Eric Biggers <ebiggers@kernel.org>,
linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
Jaegeuk Kim <jaegeuk@kernel.org>,
Victor Hsieh <victorhsieh@google.com>,
Chandan Rajendra <chandan@linux.vnet.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2 01/12] fs-verity: add a documentation file
Date: Fri, 21 Dec 2018 10:47:14 -0500 [thread overview]
Message-ID: <20181221154714.GA26547@mit.edu> (raw)
In-Reply-To: <20181221070447.GA21687@infradead.org>
On Thu, Dec 20, 2018 at 11:04:47PM -0800, Christoph Hellwig wrote:
> Ted, I think you know yourself this isn't true. Whenever we added
> useful interface to one of the major file systems we had other pick
> it up, and that is a good thing because the last thing we need is
> fragmentation of interfaces. And even if that wasn't the case I don't
> think we should take short cuts, because even if an interface was just
> for a file system or two it still needs to be properly desgined.
This is why I think the interface argument is totally bogus.
If you're OK with Darrick's suggested interface, where you pass in a
file descriptor, offset and length --- that's just a superset of the
current interface, except where the file descriptor is in the file
which is going to be protected using fs-verity. So there's if you're
OK with that interface, we can add that interface later, and it's
really no big deal; it certainly doesn't add any extra complexity for
XFS --- assuming that XFS even gets around to adding support for
fs-verity.
Adding that extra complexity is not necessary for the current users of
the interface, and as I've said multiple times before, there's no
*value* in allowing the Merkle tree to be passed in via some arbitrary
file descriptor, which might even be on a separate fhile system, as
opposed in the file which is about to be protected using fs-verity.
Linus --- we're going round and round, and I don't think this is
really a technical dispute at this point, but rather an aesthetics
one. Will you be willing to accept my pull request for a feature
which is being shippped on millions of Android phones, has been out
for review for months, and for which, if we *really* need to add
uselessly complicated interface later, we can do that? It's always
been the case for internal Kernel interfaces not to add code "just in
case" it's useful, but rather when a user turns up. I argue we should
be doing the same thing for user-space visible interfaces.
Regards,
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
Eric Biggers <ebiggers@kernel.org>,
linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-integrity@vger.kernel.org, linux-ext4@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Victor Hsieh <victorhsieh@google.com>
Subject: Re: [PATCH v2 01/12] fs-verity: add a documentation file
Date: Fri, 21 Dec 2018 10:47:14 -0500 [thread overview]
Message-ID: <20181221154714.GA26547@mit.edu> (raw)
In-Reply-To: <20181221070447.GA21687@infradead.org>
On Thu, Dec 20, 2018 at 11:04:47PM -0800, Christoph Hellwig wrote:
> Ted, I think you know yourself this isn't true. Whenever we added
> useful interface to one of the major file systems we had other pick
> it up, and that is a good thing because the last thing we need is
> fragmentation of interfaces. And even if that wasn't the case I don't
> think we should take short cuts, because even if an interface was just
> for a file system or two it still needs to be properly desgined.
This is why I think the interface argument is totally bogus.
If you're OK with Darrick's suggested interface, where you pass in a
file descriptor, offset and length --- that's just a superset of the
current interface, except where the file descriptor is in the file
which is going to be protected using fs-verity. So there's if you're
OK with that interface, we can add that interface later, and it's
really no big deal; it certainly doesn't add any extra complexity for
XFS --- assuming that XFS even gets around to adding support for
fs-verity.
Adding that extra complexity is not necessary for the current users of
the interface, and as I've said multiple times before, there's no
*value* in allowing the Merkle tree to be passed in via some arbitrary
file descriptor, which might even be on a separate fhile system, as
opposed in the file which is about to be protected using fs-verity.
Linus --- we're going round and round, and I don't think this is
really a technical dispute at this point, but rather an aesthetics
one. Will you be willing to accept my pull request for a feature
which is being shippped on millions of Android phones, has been out
for review for months, and for which, if we *really* need to add
uselessly complicated interface later, we can do that? It's always
been the case for internal Kernel interfaces not to add code "just in
case" it's useful, but rather when a user turns up. I argue we should
be doing the same thing for user-space visible interfaces.
Regards,
- Ted
next prev parent reply other threads:[~2018-12-21 15:47 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-01 22:52 [f2fs-dev] [PATCH v2 00/12] fs-verity: read-only file-based authenticity protection Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` [f2fs-dev] [PATCH v2 01/12] fs-verity: add a documentation file Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-12-12 9:14 ` Christoph Hellwig
2018-12-12 20:26 ` Eric Biggers
2018-12-13 20:22 ` Christoph Hellwig
2018-12-14 4:48 ` Eric Biggers
2018-12-17 16:49 ` Christoph Hellwig
2018-12-17 18:32 ` Eric Biggers
2018-12-19 7:09 ` Christoph Hellwig
2018-12-17 20:00 ` Darrick J. Wong
2018-12-17 20:00 ` Darrick J. Wong
2018-12-19 0:16 ` [f2fs-dev] " Theodore Y. Ts'o
2018-12-19 0:16 ` Theodore Y. Ts'o
2018-12-19 2:19 ` Dave Chinner
2018-12-19 19:30 ` Theodore Y. Ts'o
2018-12-19 21:35 ` Dave Chinner
2018-12-20 22:01 ` Theodore Y. Ts'o
2018-12-21 7:04 ` Christoph Hellwig
2018-12-21 10:06 ` Richard Weinberger
2018-12-21 15:47 ` Theodore Y. Ts'o [this message]
2018-12-21 15:47 ` Theodore Y. Ts'o
2018-12-21 15:47 ` Theodore Y. Ts'o
2018-12-21 15:53 ` Matthew Wilcox
2018-12-21 16:28 ` Theodore Y. Ts'o
2018-12-21 16:34 ` Matthew Wilcox
2018-12-21 19:13 ` Linus Torvalds
2018-12-22 4:17 ` Theodore Y. Ts'o
2018-12-22 4:17 ` Theodore Y. Ts'o
2018-12-22 22:47 ` Linus Torvalds
2018-12-23 4:34 ` Theodore Y. Ts'o
2018-12-23 4:10 ` Matthew Wilcox
2018-12-23 4:45 ` Theodore Y. Ts'o
2019-01-04 20:41 ` Daniel Colascione
2018-12-19 7:14 ` Christoph Hellwig
2018-12-19 7:11 ` Christoph Hellwig
2018-12-19 7:16 ` Linus Torvalds
2018-12-19 7:19 ` Christoph Hellwig
2018-12-14 5:17 ` Theodore Y. Ts'o
2018-12-14 5:39 ` Eric Biggers
2018-12-17 16:52 ` Christoph Hellwig
2018-12-17 19:15 ` Eric Biggers
2018-12-21 16:11 ` Matthew Wilcox
2018-11-01 22:52 ` [f2fs-dev] [PATCH v2 02/12] fs-verity: add setup code, UAPI, and Kconfig Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` [PATCH v2 03/12] fs-verity: add MAINTAINERS file entry Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` [f2fs-dev] [PATCH v2 04/12] fs-verity: add data verification hooks for ->readpages() Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` [PATCH v2 05/12] fs-verity: implement FS_IOC_ENABLE_VERITY ioctl Eric Biggers
2018-11-01 22:52 ` [f2fs-dev] [PATCH v2 06/12] fs-verity: implement FS_IOC_MEASURE_VERITY ioctl Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` [PATCH v2 07/12] fs-verity: add SHA-512 support Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` [f2fs-dev] [PATCH v2 08/12] fs-verity: add CRC-32C support Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` [f2fs-dev] [PATCH v2 09/12] fs-verity: support builtin file signatures Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` [f2fs-dev] [PATCH v2 10/12] ext4: add basic fs-verity support Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-02 9:43 ` Chandan Rajendra
2018-11-06 1:25 ` Eric Biggers
2018-11-06 6:52 ` Chandan Rajendra
2018-11-05 21:05 ` Andreas Dilger
2018-11-06 1:11 ` Eric Biggers
2018-11-01 22:52 ` [PATCH v2 11/12] ext4: add fs-verity read support Eric Biggers
2018-11-01 22:52 ` [f2fs-dev] [PATCH v2 12/12] f2fs: fs-verity support Eric Biggers
2018-11-01 22:52 ` Eric Biggers
2018-11-01 22:52 ` Eric Biggers
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=20181221154714.GA26547@mit.edu \
--to=tytso@mit.edu \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=ebiggers@kernel.org \
--cc=hch@infradead.org \
--cc=jaegeuk@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=victorhsieh@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.