I'm working on a patch to factor out some useful helper code (specifically, the glob_match() function) from drivers/ata/libata-core.c to a separate file lib/glob.c, so other drivers can use it. But I'm having a hard time figuring out how to arrange for every caller to be able to call it. In particular, suppose that CONFIG_ATA=m. I'm trying to figure out what the various options I have are for handling my new option CONFIG_GLOB. Here are the four basic possibilities (all combined with "select GLOB" by ATA): 1) bool GLOB; obj-$(CONFIG_GLOB) += glob.o I think this will atatically link the glob.o code into the kernel if CONFIG_ATA=y or CONFIG_ATA=m. So everything will work, but there's no way for an out-of-tree driver to depend on the code if CONFIG_ATA=n. (Not supporting that case for now is definitely an option.) 2) tristate GLOB; obj-$(CONFIG_GLOB) += glob.o In this case, if CONFIG_ATA=m, I'll create a separate module glob.ko. I'd need to include <linux/module.h> and add the appropriate module declarations to glob.c. Lots of code in lib/ seems to do this, but a proliferation if microscopic modules is annoying. 3) bool GLOB; lib-$(CONFIG_GLOB) += glob.o This is where I get confused. Documentation/kbuild/makefiles.txt says that glob.o will be included in the library lib.a. But it then doesn't say anything about what (if anything) is linked against lib.a. I assume (although it's not actually stated) that vmlinux is linked against it, so the linker will import any called functions. But if CONFIG_ATA=m, presumably the linker won't import glob_match(). What then will happen if ata.ko is loaded? Does it get linked statically against lib.a at module build time? Or will module loading just fail? Looking at the output of "make V=1 modules", I don't see any .a files mentioned. Is there some other magic I don't understand that will make it work? The static linking would be nice; although that would result in code duplication if multiple modules used the code, the code is awfully small (658 bytes of text) and it would take a lot of modules to make it a problem. As to what this would do to out-of-tree drivers, I have no idea... 4) tristate GLOB; lib-$(CONFIG_GLOB) += glob.o Documentation/kbuild/makefiles.txt suggests that CONFIG_GLOB=m would be synonymous with CONFIG_GLOB=y in this case, so the net effect would be identical to case 3. Am I right? May I humbly beg some guidance as to the best way to proceed? My current code takes option 2 and builds its own module if CONFIG_ATA=m, but people are asking if that's really necessary. (v1 patch at https://lkml.org/lkml/2014/5/9/663 if anyone wants more details.) The follow-on question is how to integrate the self-test code. I had defined a preprocessor symbol which allowed a standalone "gcc -DUNITTEST glob.c" to make a user-space test driver, but I've been asked to kernelize it. If using the full module route, I can just use __init code for it, like lib/list_sort.c. But for other options, its less clear. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
