All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Thulin <denis.thulin@openwide.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] i2c-tools: Adds check of i2c kernel option
Date: Tue, 4 Aug 2015 15:38:54 +0200 (CEST)	[thread overview]
Message-ID: <96448357.4733141.1438695534642.JavaMail.root@openwide.fr> (raw)
In-Reply-To: <20150804144556.58dd8978@free-electrons.com>

Hi Thomas,

----- Mail original -----
> Hello,
> 
> On Tue,  4 Aug 2015 14:27:07 +0200, Denis THULIN wrote:
> 
> > +I2C_TOOLS_DEPENDENCIES += linux
> 
> This is not acceptable: we want to allow people to build just a
> rootfs,
> and not necessarily the Linux kernel with Buildroot. I personally use
> Buildroot a lot to build a small initramfs that I then bundle in my
> kernel image, which is built separately from Buildroot (because I'm
> doing kernel development, so I build the kernel myself).

Oops. I had not thought of that.

I understand that this is a mistake for kernel options.
But could patch [1/2] be useful for the other kconfig packages ?
I think it would be useful to know options of busybox when building
packages.

> 
> Also, this is going completely backwards compared to what we've been
> doing until now. Currently, in linux/linux.mk, we have some logic to
> make sure a number of kernel options are enabled when certain
> Buildroot
> packages are enabled:
> 
>         $(if $(BR2_PACKAGE_KTAP),
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_DEBUG_FS,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_ENABLE_DEFAULT_TRACERS,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_PERF_EVENTS,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_FUNCTION_TRACER,$(@D)/.config))
>         $(if $(BR2_PACKAGE_SYSTEMD),
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_CGROUPS,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_INOTIFY_USER,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_FHANDLE,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_XATTR,$(@D)/.config))
>         $(if $(BR2_PACKAGE_SMACK),
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_SECURITY,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_SECURITY_SMACK,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_SECURITY_NETWORK,$(@D)/.config))
>         $(if $(BR2_PACKAGE_IPTABLES),
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_IP_NF_IPTABLES,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_IP_NF_FILTER,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_NETFILTER,$(@D)/.config)
>                 $(call
>                 KCONFIG_ENABLE_OPT,CONFIG_NETFILTER_XTABLES,$(@D)/.config))
> 
> However, we generally do this only when enabling the kernel option in
> question is needed to get the package to *build*. When it is
> necessary
> to make the thing run properly, or when the dependency is really
> obvious, we simply don't handle this.

Would it not be a better thing for all packages to provide a list
of kernel options they need and for LINUX_KCONFIG_FIXUP_CMDS
to select those options rather than using lots of if blocks ?

That list could also be exported so that people using a custom kernel
would know which options Buildroot would have selected had they used
the default kernel.

If it is a better thing to do, I could try to implement that,
if time allows.

Best regards,

Denis

> 
> So for example in your case, it is completely obvious that i2c-tools
> needs I2C support in the kernel, otherwise it's a tool that is quite
> useless.
> 
> Best regards,
> 
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
> 

  reply	other threads:[~2015-08-04 13:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-04 12:27 [Buildroot] [PATCH 0/2] pkg-kconfig now loads kconfig variables Denis THULIN
2015-08-04 12:27 ` [Buildroot] [PATCH 1/2] kconfig: Can now use variables outside of package Denis THULIN
2015-08-04 12:27 ` [Buildroot] [PATCH 2/2] i2c-tools: Adds check of i2c kernel option Denis THULIN
2015-08-04 12:45   ` Thomas Petazzoni
2015-08-04 13:38     ` Denis Thulin [this message]
2015-08-04 13:52       ` Thomas Petazzoni

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=96448357.4733141.1438695534642.JavaMail.root@openwide.fr \
    --to=denis.thulin@openwide.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.