All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@google.com>
To: Richard Weinberger <richard@nod.at>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net, tytso@mit.edu,
	jaegeuk@kernel.org
Subject: Re: [PATCH] fscrypto: remove unneeded Kconfig dependencies
Date: Mon, 24 Oct 2016 14:17:27 -0700	[thread overview]
Message-ID: <20161024211727.GB83082@google.com> (raw)
In-Reply-To: <c1c3502a-0364-fc31-fa7f-19125f7e0413@nod.at>

On Mon, Oct 24, 2016 at 10:41:08PM +0200, Richard Weinberger wrote:
> FWIW, Strictly speaking we could also get rid of the dependency on BLOCK.
> Only very few functions in fs/crypto/crypto.c use block specific functions,
> these could be placed in a different file.
> The use case would be very small systems with UBIFS and encrypted files.
> i.e. kexec() style bootloaders.
> 
> Thanks,
> //richard

Yes, that makes sense if UBIFS is going to be using the code too.  Feel free to
propose a patch.  As I understand it, the assumption would be that if a
filesystem needs the block-specific functions in fs/crypto/, then it itself
would necessarily already depend on CONFIG_BLOCK.  It should work to just
conditionally compile the block-specific functions based on CONFIG_BLOCK, either
via #ifdefs or by having a separate file like fs/crypto/block.c and putting
'fscrypto-$(CONFIG_BLOCK) += block.o' in fs/crypto/Makefile.  The separate file
sounds preferable.

Eric

  reply	other threads:[~2016-10-24 21:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 20:17 [PATCH] fscrypto: remove unneeded Kconfig dependencies Eric Biggers
2016-10-24 20:41 ` Richard Weinberger
2016-10-24 21:17   ` Eric Biggers [this message]
2016-11-26 20:10 ` Theodore Ts'o

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=20161024211727.GB83082@google.com \
    --to=ebiggers@google.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=richard@nod.at \
    --cc=tytso@mit.edu \
    /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.