lkml.org 
[lkml]   [2012]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: linux-next: Tree for Apr 19 (zcache)
On 04/19/2012 05:36 PM, Dan Magenheimer wrote:
>> From: Randy Dunlap [mailto:rdunlap@xenotime.net]
>> Sent: Thursday, April 19, 2012 4:30 PM
>> To: Stephen Rothwell
>> Cc: linux-next@vger.kernel.org; LKML; Dan Magenheimer
>> Subject: Re: linux-next: Tree for Apr 19 (zcache)
>>
>> On 04/18/2012 11:46 PM, Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20120418:
>>
>>
>> on x86_64:
>>
>> drivers/built-in.o: In function `zv_free':
>> zcache-main.c:(.text+0x5e1c9): undefined reference to `zs_map_object'
>> zcache-main.c:(.text+0x5e238): undefined reference to `zs_unmap_object'
>> zcache-main.c:(.text+0x5e29a): undefined reference to `zs_free'
>> drivers/built-in.o: In function `zv_create':
>> zcache-main.c:(.text+0x5e6b3): undefined reference to `zs_malloc'
>> zcache-main.c:(.text+0x5e6f0): undefined reference to `zs_map_object'
>> zcache-main.c:(.text+0x5e72c): undefined reference to `zs_unmap_object'
>> drivers/built-in.o: In function `zcache_comp_init':
>> zcache-main.c:(.text+0x5e831): undefined reference to `crypto_has_alg'
>> zcache-main.c:(.text+0x5e8a5): undefined reference to `crypto_has_alg'
>> drivers/built-in.o: In function `zcache_cpu_notifier':
>> zcache-main.c:(.text+0x5e94f): undefined reference to `crypto_alloc_base'
>> zcache-main.c:(.text+0x5e9f2): undefined reference to `crypto_destroy_tfm'
>> drivers/built-in.o: In function `zv_decompress':
>> zcache-main.c:(.text+0x5ee40): undefined reference to `zs_map_object'
>> zcache-main.c:(.text+0x5ef06): undefined reference to `zs_unmap_object'
>> drivers/built-in.o: In function `zcache_pampd_create':
>> zcache-main.c:(.text+0x5f614): undefined reference to `zs_get_total_size_bytes'
>> make[1]: *** [.tmp_vmlinux1] Error 1

The problem is that zsmalloc is being built as a module and zcache is
builtin. It seems that because CRYPTO=m, kbuild is forcing zsmalloc
to be built, just not forcing it to be builtin.

The zcache Kconfig has:
bool "Dynamic compression of swap pages and clean pagecache pages"
depends on (CLEANCACHE || FRONTSWAP) && CRYPTO && X86
select ZSMALLOC
select CRYPTO_LZO

Seems to be a nuance of kbuild I didn't know before. If a
"selected by" (sub)condition is met, if any of the conditionals are
built as modules, then the entry can be built as a module.

For example, if zsmalloc is selected by:
...(CLEANCACHE [=y] || FRONTSWAP [=n]) && CRYPTO [=m] && X86 [=y]
then it can be built as a module or builtin.

If zsmalloc is selected by:
...(CLEANCACHE [=y] || FRONTSWAP [=n]) && CRYPTO [=y] && X86 [=y]
then it must be builtin.

One fix is this:

diff --git a/drivers/staging/zcache/Kconfig b/drivers/staging/zcache/Kconfig
index 3ed2c8f..7048e01 100644
--- a/drivers/staging/zcache/Kconfig
+++ b/drivers/staging/zcache/Kconfig
@@ -2,7 +2,7 @@ config ZCACHE
bool "Dynamic compression of swap pages and clean pagecache pages"
# X86 dependency is because zsmalloc uses non-portable pte/tlb
# functions
- depends on (CLEANCACHE || FRONTSWAP) && CRYPTO && X86
+ depends on (CLEANCACHE || FRONTSWAP) && CRYPTO=y && X86
select ZSMALLOC
select CRYPTO_LZO
default n
I think this is the best way since ZCACHE is a bool and CRYPTO is the only
one of the dependencies that is a tristate. This forces both ZSMALLOC and
CRYPTO_LZO to be builtin if ZCACHE is selected.

Any other suggestions?

Thanks,
Seth



\
 
 \ /
  Last update: 2012-04-20 06:43    [W:0.067 / U:11.020 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site