Checking whether a certain CONFIG_* is set
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set
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:
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> 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).
Quoted 9 lines
Quoted 4 lines
Yes, I'm thinking about it...
I think the plan I'll be goign with is to add a hidden
Kconfigknob 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.
Quoted 9 lines
Quoted 5 lines
- 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.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'