mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	ecryptfs-devel@lists.launchpad.net,
	Dave Hansen <dave@linux.vnet.ibm.com>
Subject: Re: [PATCH -mmotm] ecryptfs: depends on CRYPTO
Date: Mon, 28 Sep 2009 17:20:24 -0700	[thread overview]
Message-ID: <20090928172024.9f944f16.randy.dunlap@oracle.com> (raw)
In-Reply-To: <4AC15058.8020709@linux.vnet.ibm.com>

On Mon, 28 Sep 2009 19:10:00 -0500 Tyler Hicks wrote:

> On 09/28/2009 03:34 PM, Randy Dunlap wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> > 
> > ecryptfs uses crypto APIs so it should depend on CRYPTO.
> > Otherwise many build errors occur. [63 lines not pasted]
> > 
> > Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> > ---
> >  fs/ecryptfs/Kconfig |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- mmotm-2009-0925-1435.orig/fs/ecryptfs/Kconfig
> > +++ mmotm-2009-0925-1435/fs/ecryptfs/Kconfig
> > @@ -1,6 +1,6 @@
> >  config ECRYPT_FS
> >  	tristate "eCrypt filesystem layer support (EXPERIMENTAL)"
> > -	depends on EXPERIMENTAL && KEYS && NET
> > +	depends on EXPERIMENTAL && KEYS && NET && CRYPTO
> >  	select CRYPTO_ECB
> >  	select CRYPTO_CBC
> >  	help
> 
> Hi Randy - Thanks for the patch!  Unfortunately, I think it defeats what
> Dave Hansen was wanting to do with commit
> 382684984e93039a3bbd83b04d341b0ceb831519.
> 
> When I pulled that patch in, I was under the assumption that the select
> would also select all necessary dependencies.  According to
> Documentation/kbuild/kconfig-language.txt, that's not the case:
> 
> 	select should be used with care. select will force
> 	a symbol to a value without visiting the dependencies.
>         By abusing select you are able to select a symbol FOO even
>         if FOO depends on BAR that is not set.
> 
> Maybe we should do it how other folks are tackling this problem and
> select CRYPTO, along with CRYPTO_ECB and CRYPTO_CBC.  While we're at it,
> we should probably throw in CRYPTO_AES (aes-128 is the default cipher,
> but the cipher is configurable at mount so it might be too obtrusive for
> us to select it) and CRYPTO_MD5 (our default hash alg, not currently
> configurable).  Also, we don't depend on NET anymore because our netlink
> interface is no longer around.  It may not hurt to select KEYS, rather
> than depend on it.  Does all of this sound sane to you?

It selects too much stuff.  "select" should not be used to enable
a full subsystem (that's my general rule, not in kconfig-language.txt).
What kconfig-language.txt says that applies here is just after your
quoted text:

	In general use select only for non-visible symbols
	(no prompts anywhere) and for symbols with no dependencies.
	That will limit the usefulness but on the other hand avoid
	the illegal configurations all over.

CRYPTO does not fit that.

One of the big problems with selecting kconfig symbols (like subsystem
ones) is that it makes it difficult to disable that symbol, which some
of us often want to do.


---
~Randy

  reply	other threads:[~2009-09-29  0:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-25 21:35 mmotm 2009-09-25-14-35 uploaded akpm
2009-09-28  6:42 ` Question: RCU stall detected in memcg (Re: " KAMEZAWA Hiroyuki
2009-09-28  8:33   ` KAMEZAWA Hiroyuki
2009-09-28  9:06   ` [BUGFIX][PATCH][rc1] memcg: fix refcnt goes to minus KAMEZAWA Hiroyuki
2009-09-28  9:13     ` [PATCH][rc1] cgroup: catch bad css refcnt at css_put KAMEZAWA Hiroyuki
2009-09-28 14:20       ` Paul Menage
2009-09-29  3:06         ` KAMEZAWA Hiroyuki
2009-09-29  0:50       ` Li Zefan
2009-09-29  2:55         ` KAMEZAWA Hiroyuki
2009-09-29  3:09         ` [PATCH][rc1] cgroup: catch bad css refcnt at css_put v2 KAMEZAWA Hiroyuki
2009-09-28  9:32     ` [BUGFIX][PATCH][rc1] memcg: fix refcnt goes to minus Balbir Singh
2009-09-28 11:22       ` KAMEZAWA Hiroyuki
2009-09-28  9:22   ` Question: RCU stall detected in memcg (Re: mmotm 2009-09-25-14-35 uploaded Balbir Singh
2009-09-28 11:26     ` KAMEZAWA Hiroyuki
2009-09-28  9:34   ` Paul E. McKenney
2009-09-28 11:30     ` KAMEZAWA Hiroyuki
2009-09-28 20:34 ` [PATCH -mmotm] ecryptfs: depends on CRYPTO Randy Dunlap
2009-09-29  0:10   ` Tyler Hicks
2009-09-29  0:20     ` Randy Dunlap [this message]
2009-09-29 17:08       ` Tyler Hicks
2009-09-29 17:17         ` Randy Dunlap

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=20090928172024.9f944f16.randy.dunlap@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=ecryptfs-devel@lists.launchpad.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tyhicks@linux.vnet.ibm.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

all inboxes | Powered by JetHome®