Re: [PATCH -mmotm] ecryptfs: depends on CRYPTO

[Tyler Hicks]

On 09/28/2009 03:34 PM, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
> 
> 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@xxxxxxxxxx>
> ---
>  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?

Tyler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/