On Mon, Dec 19, 2022 at 11:36 AM Greg KH <greg@kroah.com> wrote:
On Mon, Dec 19, 2022 at 10:02:42AM -0700, jim.cromie@gmail.com wrote:
On Mon, Dec 19, 2022 at 9:37 AM <jim.cromie@gmail.com> wrote:
Id like to build 2 modules (with different names) from a single source file, with 2nd being dependent on the 1st.
Specifically, Ive got: lib/test_dynamic_debug.c
I want A: lib/test_dynamic_debug.ko B: lib/test_dynamic_debug_submod.ko
I expect that the code just needs an #ifdef #else #endif block to clearly put the dependor & dependee elements next to each other.
My question is how to do this in the Makefile ? this does most of it
--- a/lib/Makefile +++ b/lib/Makefile @@ -78,7 +78,8 @@ obj-$(CONFIG_TEST_SORT) += test_sort.o obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o -obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o +obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o test_dynamic_debug_submod.o +CFLAGS_test_dynamic_debug_submod.o += -DTEST_DYNAMIC_DEBUG_SUBMOD obj-$(CONFIG_TEST_PRINTF) += test_printf.o
but how do I tell it the 2nd target ?
more to the point, this doesnt work (nor do permutations), I miss something:
+($obj)/test_dynamic_debug_submod.o: ($obj)/test_dynamic_debug.c
Pleaase don't do that :(
If you _REALLY_ need to do this, then just #include your .c file into two other .c files. And keep everything in your #included .c file static to make sure you don't have duplicate global symbols.
that approach works perfectly, thanks. and no CFLAGs or weird rules in the Makefile. dependent module is 2 lines - define, include.
Otherwise it is impossible for the same .o to be linked into two different modules (or into the kernel image itself) as there will be duplicate global symbols (as that .c file had to have something global for you to be able to call into it.)
But step back, what is the problem that you really want to solve here that you feel somehow a single .c file built twice would be correct? Especially with code in lib/ that should not be needed at all as you are building "library" functions that only get included if they are actually used in the large kernel image.
Heres my story: CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression; i915.ko depends upon drm.ko, which is loaded 1st. drm.debug=<something> is set as last step in the modprobe drm, ie before modprobe i915 is run. So i915's drm_dbg callsites arent enabled at module_init, or later. Once drm.debug is updated again (post modprobe), dyndbg's param-callback applies the drm.debug bits to enable the DRM_UT_* classes, this time seeing i915 and drm-* helpers too. The fix Im working on splits DECLARE_DYNDBG_CLASSMAP into DYNDBG_CLASSMAP_DEFINE & DYNDBG_CLASSMAP_USE. This comports better with K&R define-once, refer-many model, and distinguishes _USErs (i915, helpers) from DEFINEr (drm). So classmap users get cataloged separately, and get extra behavior, to lookup the state var of the definer of the param, and apply it to the module being loaded. I need to recapitulate this dependent module scenario. In test_dynamic_debug, Ive reworked the DECLARE_*s to ifdef'd _DEFINE and _USE blocks. this makes the parent/child distinction very clear. Using the same code 2x means that logging is same baseline for both. It should mean that ALL the enablements are duplicated, which should be easy to verify.
thanks,
greg k-h