On 11 Nov 2022, Nick Alcock said: > But... it's not quite doing the same thing, so perhaps it can't be that > much simpler. Picking the first item that appears in my test build of > this but not in modules_thick.builtin: > > +arch/x86/crypto/libblake2s-x86_64.o: arch/x86/crypto/blake2s-core.o arch/x86/crypto/blake2s-glue.o > > But... > > obj-$(CONFIG_CRYPTO_BLAKE2S_X86) += libblake2s-x86_64.o > libblake2s-x86_64-y := blake2s-core.o blake2s-glue.o > > config CRYPTO_BLAKE2S_X86 > bool "Hash functions: BLAKE2s (SSSE3/AVX-512)" > > This cannot be built as a module. The point of modules_thick.builtin was > not to capture things that can be built into the kernel or left > unconfigured entirely (though that is *also* a nice thing to capture, > and should probably be captured regardless) but to capture *those things > that can possibly be built as modules*, i.e. those things which are > tristates in Kbuild and might possibly get built into .ko's. That was > the whole reason we needed the tristate stuff in the first place, and > I'm still not sure how to do it without that. OK, I think I should be able to combine your patch with (a variant of) the tristate stuff and get the best of both worlds (only-modular plus the efficiency of building and simplicity of your patch, with no nasty separate recursion like I had for modules_thick.builtin). Working on that...
