Kconfig in external modules

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

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,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180222/9c502417/attachment.sig>

I see. Thanks for explaining.

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.

Your email ends abruptly, I guess something wrong happened. Could you resend this part?

Thanks,
~ Gustavo

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.

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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180222/f69cd0d9/attachment-0001.sig>

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