Hi all, The kbuild documentation states that is possible to use CONFIG_ options in external (out-of-tree) modules. However, is it possible for an external module to define new options in a local Kconfig file? For example, I would have 2 files /path/to/module/Kconfig /path/to/module/.config when I run the usual command to build external module $ make -C /lib/modules/`uname -r`/build M=/path/to/module modules the options present in the local .config file would be exported by kbuild as C #define's and make variables to be used in the module. The build system supports such feature? Thanks, ~ Gustavo
On Thu, 22 Feb 2018 10:06:43 -0300, Gustavo Leite said:
when I run the usual command to build external module
$ make -C /lib/modules/`uname -r`/build M=/path/to/module modules
the options present in the local .config file would be exported by kbuild as C #define's and make variables to be used in the module. The build system supports such feature?
This is probably a Bad Idea, because it results in a module that was built against a different .config than the kernel it is loaded into. All sorts of things can go wrong (for instance, consider if your local Kconfig did a 'select' to turn on a CONFIG_ variable that wasn't on in the main kernel config). You should just get the module fixed so it can be upstreamed and in-tree rather than live life as an external module (plus, if you do that, you no longer need to do all the updating of code when in-kernel API's change ;) If you need config options for a module,
On Thu, Feb 22, 2018 at 08:37:08AM -0500, valdis.kletnieks@vt.edu wrote:
This is probably a Bad Idea, because it results in a module that was built against a different .config than the kernel it is loaded into. All sorts of things can go wrong (for instance, consider if your local Kconfig did a 'select' to turn on a CONFIG_ variable that wasn't on in the main kernel config).
I see. Thanks for explaining.
You should just get the module fixed so it can be upstreamed and in-tree rather than live life as an external module (plus, if you do that, you no longer need to do all the updating of code when in-kernel API's change ;)
Well, I'm new to module programming and I'm interested in academic research on NUMA balancing techniques. This module is where I intend to test new ideas and it is definitely not ready for merging upstream. This is the reason it will probably remain as an external module.
If you need config options for a module,
Your email ends abruptly, I guess something wrong happened. Could you resend this part? Thanks, ~ Gustavo
On Thu, 22 Feb 2018 11:13:09 -0300, Gustavo Leite said:
Well, I'm new to module programming and I'm interested in academic research on NUMA balancing techniques. This module is where I intend to test new ideas and it is definitely not ready for merging upstream. This is the reason it will probably remain as an external module.
I'm not sure that NUMA balancing is something you'll be able to do in a module - I am pretty sure that not all the infrastructure you'll need is accessible from a module. If you're ending up tossing EXPORT_SYMBOL() all over the place, making your own code a module isn't going to help. Plus, one of the big reasons to use modules while developing is so you can just insmod/rmmod and iterate testing without needing to reboot. I doubt that you'll be able to remain constrained to balancing techniques that support an rmmod - the kernel doesn't have much infrastructure to defend against race conditions against module removal other than the reference count against the module itself.
If you need config options for a module,
Your email ends abruptly, I guess something wrong happened. Could you resend this part?
Derp. That was from a previous draft and not removed - I think it was the first line scrolled out of sight in the mail edit buffer. :)
On Thu, Feb 22, 2018 at 10:15:43AM -0500, valdis.kletnieks@vt.edu wrote:
I'm not sure that NUMA balancing is something you'll be able to do in a module - I am pretty sure that not all the infrastructure you'll need is accessible from a module. If you're ending up tossing EXPORT_SYMBOL() all over the place, making your own code a module isn't going to help.
Right. I imagined it wouldn't be possible. All in all, module programming seems like a good place to start learning about the kernel API and its inner workings. Thanks once more :) ~ Gustavo
participants (2)
-
Gustavo Leite -
valdis.kletnieks＠vt.edu