[OE-core] how can i tell which default kernel config OE started with?

Bruce Ashfield bruce.ashfield at gmail.com
Tue May 3 14:39:19 UTC 2016


On Tue, May 3, 2016 at 9:12 AM, Robert P. J. Day <rpjday at crashcourse.ca>
wrote:

> On Tue, 3 May 2016, Bruce Ashfield wrote:
>
> >
> >
> > On Tue, May 3, 2016 at 6:53 AM, Robert P. J. Day <rpjday at crashcourse.ca>
> wrote:
> >
> >         (actually, working in wind river linux but i suspect the answer
> will
> >       be the same.)
> >
> >         i've defined a target board and, rather than supplying a full
> >       "defconfig" file as a starting point for kernel configuration, my
> BSP
> >       layer starts by applying a "kernel_baseline.cfg" file which
> contains
> >       only a couple hundred settings that i am particularly interested
> in.
> >
> >         so, given that, how can i tell what OE chose as a starting point
> for
> >       a .config file before beginning to apply my kernel config
> fragments?
> >       i'm poking around in the log files of the build, but i can't seem
> to
> >       see where the "configme" process selects a starting point. am i
> just
> >       missing the obvious? i want to see the .config file *before* any
> of my
> >       fragments are applied.
> >
> >
> > If you haven't specified a defconfig (in-tree, or in your layer),
> > and are only using fragments, then it will be the first fragment.
> > There's no logic to go out and find a baseline, since it would
> > almost always not be what someone wanted.
>
>   ok, i'm going to ask a few follow-up questions since i clearly don't
> totally understand the full kernel configuration process.
>
>
That's because it varies a bit, based on the kernel and options :)


>   i have a BSP layer for a target board that first specifies a
> "kernel_baseline.cfg" fragment file which contains just those kernel
> config settings i want to make sure are set, and that file is just
> over 200 lines long. i also drag in a few other *very* short .cfg
> files. but in the end, the .config file generated under
> .../linux-windriver/4.1-r0/linux-cxii-standard-build/ is almost 2,200
> lines long. where did all that extra content come from?
>


The .config is always the setting for all reachable kernel options. Some
are set in fragments, or defconfigs, others are the result of  'select'
and defaults by the kernel itself, etc.

If you run savedefconfig, you can see the non default options that were
set.


>
>   i'm assuming (and i could be wrong here) that since i'm using the
> line:
>
> TARGET_SUPPORTED_KTYPES = "standard"
>
> i'm automatically incorporating "standard"-related content under
> .../kernel-meta/ktypes/standard? as in, the files:
>
>   * standard.cfg
>   * standard.scc
>
> or am i mistaken? from where comes all that additional content that
> ends up in the final .config?  is there a record of it in a log file
> somewhere?
>

If you are not supplying a defconfig, and are inheriting the standard
kernel options, then yes, you'd be getting those fragments as well.

You can look in the work-shared/ .. kernel-source/.kernel-meta/ directory
for the meta-series (if using linux-yocto derived kernels), and that will
reference
everything that was used to configure and patch the kernel. If it isn't in
there,
it was a default or select by the kernel itself.

Bruce


>
>   couple more kernel config-related questions coming shortly ...
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160503/a3106db7/attachment-0002.html>


More information about the Openembedded-core mailing list