On 04/19/2012 05:36 PM, Dan Magenheimer wrote: >> From: Randy Dunlap [mailto:rdunlap@xxxxxxxxxxxx] >> Sent: Thursday, April 19, 2012 4:30 PM >> To: Stephen Rothwell >> Cc: linux-next@xxxxxxxxxxxxxxx; 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
