[Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set

[Yann E. MORIN <yann.morin.1998@free.fr>]

Peter, All,

On 2015-08-21 22:28 +0200, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>  >> > I think the plan I'll be goign with is to add a hidden Kconfig knob that
>  >> > packages that want to build a kernel module will have to select.
>  >> 
>  >> Why not just like the kernel-module infrastructure handle it like I
>  >> proposed? I don't think it is very nice that people have to remember to
>  >> add the select as well (and chances are they won't notice if they
>  >> forget).
> 
>  > Because that would not work for packages in br2-external trees, as I
>  > already explained.
> 
> Are you sure? I didn't try it, but as we only *USE* the variable when
> LINUX_KCONFIG_FIXUP_CMDS runs, which is after all the .mk files have
> been parsed I think it should work?

Ah, just checking would indeed be doable, something similar (but more
restrictive) to the patch proposed by Jan:
    https://patchwork.ozlabs.org/patch/508729/

I.e. somthing like:

    define $(2)_KERNEL_MODULES_BUILD
        if ! grep -E "^CONFIG_MODULES=y\$$" $$(LINUX_DIR)/.config >/dev/null; then \
            printf "Error: your Linux kernel does not support modules\n"; \
            exit 1; \
        fi
        [--current code--]
    endef

Yes, that would work.

But I was focused on actually enabling the CONFIG_MODULES option when a
package wants to build a kernel module, and _that_ is not possible with
the kernel-module infra.

> > I know you are not using br2-external (and also do not really see the
>  > point of it), but a lot of people find this to be a really important
>  > feature. I also suspect some of our (corporate) users did choose
>  > Buildroot (partly) because of br2-external.
> 
> It's true that I don't personally use br2-external and don't find it
> such a killer feature, I *DO* acknowledge that some people do (which is
> why I merged the support for it in the first place) and will try to keep
> it working as good as possible.

OK, thanks! :-)

> With that said, we have a lot of other
> requirements for Buildroot (like keeping it simple), so will not bend
> over backwards to improve br2-external support if it means making big
> compromises elsewhere.

I do agree with that.

> br2-external stuff will always been more limited than normal packages in
> the tree.

Yes, probably. But what I argue is that we should not introduce
_arbitrary_ restrictions that we can easily avoid. And by "easily", I do
agree that it should not require huge changes in Buildroot, be simple
code, be simple to understand and be simple to use.

>  >> Like Thomas says, we are already doing the 2nd option and I think it
>  >> makes sense to keep on doing so - So I don't think there's a common need
>  >> for the first.
> 
>  > Still, we are currently not allowing another package to set kernel
>  > options _from_ that package's .mk file. All we have is the kernel
>  > (de)activating options based on the presence of other packages, and that
>  > excludes packages from br2-external. Unless Buildroot is modified
>  > accordingly (but then br2-external looses its attractiveness for that
>  > package).
> 
> Ok, but if all of these use the kernel-module infrastructure (which
> linux.mk knows about), then this should work for CONFIG_MODULES, right?

No, linux.mk does not know of the kernel-module infra. The kernel-module
infra is entirely implemented using post-build and post-install hooks of
the package itself, not of the kernel.

Maybe you confused kernel-module with the linux extensions?

So I guess I start to see where the misunderstanding comes from... The
kernel-module infra can indeed _check_ that CONFIG_MODULES is set, but
it can not set it.

(Arguably, we could do it for in-tree packages, because their .mk are
parsed before that of the kernel, so we could set a Makefiel variable to
tell linux.mk to enable CONFIG_MODULES. But since br2-external packages
are parsed after linux.mk, then we could not for those packages).

So, I've decided to prepare two patch series, and we can apply the one
that gets consensus:
  - one that does the check in the kernel-module infra,
  - one that forces CONFIG_MODULES when required.

When both are ready, I'll push them to the list.

I hope we can get either in *before* the release: the kernel-module
infra is brand new in this cycle, and I'd like we get a stable "API"
for it before releasing it to the wild.

> It naturally cannot work for random other config settings.

ACK.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'