From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Ilya Dmitrichenko <errordeveloper@gmail.com>,
yocto <yocto@yoctoproject.org>
Subject: Re: Kernel features
Date: Sun, 7 Sep 2014 10:17:04 -0400 [thread overview]
Message-ID: <540C68E0.5050907@windriver.com> (raw)
In-Reply-To: <CAPhDKbFei3vk24Zt2K169DGW+_QLhEWtV+MGXFPOgOr8TFFX0w@mail.gmail.com>
On 2014-09-07, 4:51 AM, Ilya Dmitrichenko wrote:
> Today I have spent quite a while trying to figure how KERNEL_FEATURES
> works and why some of the things I pass in my configuration fragment
> are not getting enabled.
>
> It turned out that some of the options no longer existed and some had
> been renamed.
Do you have an example ? We try and not rename or remove public facing
configuration fragments, and hide the changing CONFIG_* values behind
the fragment names.
>
> The question is really why would this not get detected by
> kernel_configcheck or any other step?
>
> I'm guessing this might be the case of how kconfig works, perhaps...
> So I wonder whether anyone have looked into how we could actually get
> the feature dependency graph from kconfig to bitbake or at least some
> sort of helper tool? Perhaps parsing kconfig manifests in Python would
> be a starting point...
There have been many efforts are changing, writing and processing
Kconfig constructs in other languages .. they all end up being
pretty much a re-implementation of Kconfig, and hence a big effort
that needs to be continuously maintained over time .. also a big
effort.
But maybe I'm not quite understanding your question, if you can
send along an example, that might help.
Cheers,
Bruce
>
> Cheers,
>
next prev parent reply other threads:[~2014-09-07 14:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-07 8:51 Kernel features Ilya Dmitrichenko
2014-09-07 14:17 ` Bruce Ashfield [this message]
2014-09-08 5:50 ` Ilya Dmitrichenko
2014-09-08 12:14 ` Bruce Ashfield
2014-09-08 12:31 ` Include PaX / GRSecurity Jens Lucius
[not found] ` <CAPhDKbH3sj49qfuBnKY-JvD2AGarFpx1PnSOij67Uvr3gABeTg@mail.gmail.com>
2014-09-08 18:07 ` Kernel features Ilya Dmitrichenko
2014-09-08 20:02 ` Bruce Ashfield
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=540C68E0.5050907@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=errordeveloper@gmail.com \
--cc=yocto@yoctoproject.org \
/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.