From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set
Date: Wed, 19 Aug 2015 21:05:34 +0200 [thread overview]
Message-ID: <20150819190534.GA13372@free.fr> (raw)
In-Reply-To: <20150819194643.1fad6062@free-electrons.com>
Thomas, Jan, All,
On 2015-08-19 19:46 +0200, Thomas Petazzoni spake thusly:
> On Wed, 19 Aug 2015 15:14:34 +0200, Jan Viktorin wrote:
>
> > this short patch series introduces a way how to check whether certain
> > CONFIG_* entries are set to an expected value in a selected .config
> > file. When building a package that requires a certain CONFIG_* to be
> > set (as in the case of xtables-addons), Buildroot can either force
> > to set the config or just error out a message.
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.
> > I could not find any suitable mechanism for this in Buildroot (if there
> > is one, please give me a reference) so I propose a simple extension of
> > KCONFIG_*_OPT util macros. It is then implemented for xtables-addons to
> > check whether CONFIG_MODULES are set in the Linux Kernel .config.
>
> There is some discussion already going on on this topic, around the
> pkg-kernel-module infrastructure. We recently committed a patch that
> makes the infrastructure verify that the kernel has been built with
> module support, and if not, bail out with a clear error message:
>
> http://git.buildroot.net/buildroot/commit/?id=8df95d926e963601c727defeb4ab90ce2368da70
>
> However, Peter Korsgaard raised the concern that we should instead just
> forcefully enable CONFIG_MODULES=y in the configuration in such a case.
> There has then been some discussion with Yann on how to achieve that
> properly. Please see the thread at
> http://lists.busybox.net/pipermail/buildroot/2015-August/137511.html.
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.
Then, if that option is set, we can force-on support for modules in
linux.mk. Note: if the option is not set, we would *not* disable support
for modules, and let it as set in the user-provided (def)config file.
So, all in all, that would solve the xtables-addons issue, because we
would be handling CONFIG_MODULE explicitly.
Now, there are two questions:
- 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?
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. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2015-08-19 19:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-17 16:50 [Buildroot] xtables-addons does not build for arm kernel 4.1.4 Jan Viktorin
2015-08-17 21:52 ` Peter Korsgaard
2015-08-17 22:35 ` Jan Viktorin
2015-08-19 13:14 ` [Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set Jan Viktorin
2015-08-19 13:14 ` [Buildroot] [PATCH v1 1/2] pkg-utils: Define KCONFIG_ASSERT_OPT macro Jan Viktorin
2015-08-19 19:16 ` Yann E. MORIN
2015-08-19 13:14 ` [Buildroot] [PATCH v1 2/2] xtables-addons: test CONFIG_MODULES=y in the kernel Jan Viktorin
2015-08-19 17:46 ` [Buildroot] [PATCH v1 0/2] Checking whether a certain CONFIG_* is set Thomas Petazzoni
2015-08-19 19:05 ` Yann E. MORIN [this message]
2015-08-19 19:08 ` Thomas Petazzoni
2015-08-19 19:21 ` Yann E. MORIN
2015-08-19 20:23 ` Thomas Petazzoni
2015-08-19 21:05 ` Peter Korsgaard
2015-08-21 13:22 ` Yann E. MORIN
2015-08-21 13:41 ` Jeremy Rosen
2015-08-21 20:28 ` Peter Korsgaard
2015-08-21 21:05 ` Yann E. MORIN
2015-08-21 22:17 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150819190534.GA13372@free.fr \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.