[Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set
Yann E. MORIN
yann.morin.1998 at free.fr
Fri Aug 21 13:22:27 UTC 2015
Peter, All,
[I forgot to send that one; it got stuck in my draft folder...]
On 2015-08-19 23:05 +0200, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998 at free.fr> writes:
> > Arguably, xtables-addons should be (if possible) converted over to using
> > the kernel-modules infra, which should (will) take care of that (in the
> > future). I'll try to see if I can convert it.
> Yeah, agreed.
I'll be working on it (not trivial from a first look).
> > Yes, I'm thinking about it...
>
> > 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.
And I do *not* want that we treat packages from br2-external differently
that the in-tree ones [*].
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.
[*] there already are a few use-cases that br2-external does not and
can't solve, because of the way Buildroot is designed, see below for an
example; let's not add arbitrary limitations that we can very easily
avoid.
> > - will we need to _check_ for any arbitrary kernel option to be set,
> > and offer packages a simple mean to do so?
>
> > - will we need to _force_ (on or off) any other kernel option, and
> > offer packages a simple mean to do so?
>
> 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).
Note: I never said we should provide a way for packages to enable or
disable arbitrary kernel options. I was just asking.
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. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list