Kconfig in external modules

Kconfig in external modules

[Gustavo Leite]

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

Kconfig in external modules

[valdis.kletnieks at vt.edu]

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,
-------------- 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>

Kconfig in external modules

[Gustavo Leite]

On Thu, Feb 22, 2018 at 08:37:08AM -0500, valdis.kletnieks at 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

Kconfig in external modules

[valdis.kletnieks at vt.edu]

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. :)
-------------- 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>

Kconfig in external modules

[Gustavo Leite]

On Thu, Feb 22, 2018 at 10:15:43AM -0500, valdis.kletnieks at 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