From: Darren Hart <dvhart@infradead.org>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
Andy Shevchenko <andy@infradead.org>,
Linus Walleij <linusw@kernel.org>,
Enrico Weigelt <info@metux.net>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Platform Driver <platform-driver-x86@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
linux-kbuild@vger.kernel.org
Subject: Re: [PATCH 2/3] x86: apuv2: fix input dependencies
Date: Wed, 6 Mar 2019 23:03:36 -0800 [thread overview]
Message-ID: <20190307070336.GI44339@wrath> (raw)
In-Reply-To: <82c978b2-e9c4-e178-e4b7-621729c2cee4@metux.net>
On Thu, Mar 07, 2019 at 01:10:13AM +0100, Enrico Weigelt, metux IT consult wrote:
> On 05.03.19 14:56, Andy Shevchenko wrote:
> >
> > Darren gave a talk about merging kernel configs to get something like
> > you want to.
> > This tool is quite long already lying around. merge_config.sh in your
> > kernel source tree.
>
> Yes, that's similar to how some distros (eg. yocto) do it.
>
I wrote merge_config.sh to replace and simplify some of the yocto
tooling. With merge_config upstream, Yocto now uses it directly.
> But my requirements are a bit more complex:
>
> In my final meta-config, I just wanna say:
>
> * i have board A (possibly multiple boards)
> * i need features X, Y, Z (eg. eth, display, can, ext4, acl, ...)
>
> And that shall be all to generate a minimal config for exactly those
> requirements.
That's also the goal of the Yocto configuration fragments, and is
possible with merge_config with a set of defined fragments.
>
> Doing that by just putting config snippets together, quickly turns into
> a maintenance hell. At least you'd need recursive dependencies and some
> if/else logic.
>
> That's why I've written kmct:
>
> https://github.com/metux/kmct
I had a look, the README could benefit from a basic usage example.
Digging through it further, it appears that you are creating yaml files
which contain CONFIGs. The problem with this in my opinion is these are
kernel version specific, so you know have a lot of boiler plate yaml
wrapping kernel version specific CONFIG options which will slowly get
out of sync over time. This is the usual argument for keeping config
fragments together with the kernel - and why we do that in arch/*/config
for example.
Perhaps I'm missing your desired workflow though. I tend to find the
options I need and record them in a fragment, and save it off for later
to quickly be able to "make defconfig fragA.config fragB.config" etc. Is
what you're trying to do different?
--
Darren Hart
VMware Open Source Technology Center
next prev parent reply other threads:[~2019-03-07 7:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-04 20:19 [PATCH 1/3] x86: apuv2: remove unused variable Arnd Bergmann
2019-03-04 20:19 ` [PATCH 2/3] x86: apuv2: fix input dependencies Arnd Bergmann
2019-03-05 0:18 ` Enrico Weigelt, metux IT consult
2019-03-05 8:23 ` Arnd Bergmann
2019-03-05 13:50 ` Enrico Weigelt, metux IT consult
2019-03-05 13:56 ` Andy Shevchenko
2019-03-07 0:10 ` Enrico Weigelt, metux IT consult
2019-03-07 7:03 ` Darren Hart [this message]
2019-03-05 16:46 ` Arnd Bergmann
2019-03-04 20:19 ` [PATCH 3/3] x86: apuv2: select LEDS_CLASS Arnd Bergmann
2019-03-05 0:03 ` Enrico Weigelt, metux IT consult
2019-03-05 0:09 ` Randy Dunlap
2019-03-08 9:05 ` Linus Walleij
2019-03-05 0:04 ` [PATCH 1/3] x86: apuv2: remove unused variable Enrico Weigelt, metux IT consult
2019-03-05 13:47 ` Andy Shevchenko
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=20190307070336.GI44339@wrath \
--to=dvhart@infradead.org \
--cc=andy.shevchenko@gmail.com \
--cc=andy@infradead.org \
--cc=arnd@arndb.de \
--cc=info@metux.net \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@metux.net \
--cc=platform-driver-x86@vger.kernel.org \
--cc=yamada.masahiro@socionext.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).