From: Niels de Vos <ndevos@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Theodore Ts'o <tytso@mit.edu>,
linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, Xiubo Li <xiubli@redhat.com>,
Marcel Lauhoff <marcel.lauhoff@suse.com>
Subject: Re: [RFC 0/4] fs: provide per-filesystem options to disable fscrypt
Date: Fri, 18 Nov 2022 14:13:58 +0100 [thread overview]
Message-ID: <Y3eFFrhT3b0yoti9@ndevos-x1> (raw)
In-Reply-To: <Y3HZ/To8z76vBqYo@infradead.org>
On Sun, Nov 13, 2022 at 10:02:37PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 10, 2022 at 05:47:10PM +0100, Niels de Vos wrote:
> > And, there actually are options like CONFIG_EXT4_FS_POSIX_ACL and
> > CONFIG_EXT4_FS_SECURITY. Because these exist already, I did not expect
> > too much concerns with proposing a CONFIG_EXT4_FS_ENCRYPTION...
>
> ext4 is a little weird there as most file systems don't do that.
> So I think these should go away for ext4 as well.
Yeah, I understand that there is a preference for reducing the number of
Kconfig options for filesystems. That indeed would make it a little
easier for users, so I am supportive of that as well.
> > Note that even with the additional options, enabling only
> > CONFIG_FS_ENCRYPTION causes all the filesystems that support fscrypt to
> > have it enabled. For users there is no change, except that they now have
> > an option to disable fscrypt support per filesystem.
>
> But why would you do that anyay?
An other mail in this thread contains a description about that. It is
more about being able to provide a kernel build that is fully tested,
and enabling more options (or being unable to disable features)
increases the testing efforts that are needed.
However, as Ted pointed out, there are other features that can not be
disabled or limited per filesystem, so there will always be a gap in
what can practically be tested.
Thanks,
Niels
next prev parent reply other threads:[~2022-11-18 13:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 14:12 [RFC 0/4] fs: provide per-filesystem options to disable fscrypt Niels de Vos
2022-11-10 14:12 ` [RFC 1/4] fscrypt: introduce USE_FS_ENCRYPTION Niels de Vos
2022-11-10 14:12 ` [RFC 2/4] fs: make fscrypt support an ext4 config option Niels de Vos
2022-11-10 14:12 ` [RFC 3/4] fs: make fscrypt support a f2fs " Niels de Vos
2022-11-10 14:12 ` [RFC 4/4] fs: make fscrypt support a UBIFS " Niels de Vos
2022-11-10 15:38 ` [RFC 0/4] fs: provide per-filesystem options to disable fscrypt Theodore Ts'o
2022-11-10 16:47 ` Niels de Vos
2022-11-10 18:15 ` Theodore Ts'o
2022-11-10 18:43 ` Theodore Ts'o
2022-11-18 13:05 ` Niels de Vos
2022-11-14 6:02 ` Christoph Hellwig
2022-11-18 13:13 ` Niels de Vos [this message]
2022-11-16 2:10 ` Eric Biggers
2022-11-18 13:25 ` Niels de Vos
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=Y3eFFrhT3b0yoti9@ndevos-x1 \
--to=ndevos@redhat.com \
--cc=hch@infradead.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel.lauhoff@suse.com \
--cc=tytso@mit.edu \
--cc=xiubli@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox