* Re: Magic kernel config option.
@ 2013-01-02 21:11 Brian Smucker
2013-01-02 21:12 ` Bruce Ashfield
0 siblings, 1 reply; 8+ messages in thread
From: Brian Smucker @ 2013-01-02 21:11 UTC (permalink / raw)
To: yocto@yoctoproject.org, Bruce Ashfield
On 1/2/2013 10:06 AM, Bruce Ashfield wrote:
> On 12-12-24 02:59 PM, Brian Smucker wrote:
>> Hi,
>>
>
> Catching up on email from the holidays. Did you ever get an answer
> to this ?
Not yet, resumed my quest today.
>> I'm a yocto mostly-newbie, trying to find my way. I have a custom layer
>> that I am using to build a kernel. The layer right now consists of a few
>> kernel patches and a defconfig and is based on the standard kernel
>> otherwise.
>>
>> When I do a diff on my defconfig and the bitbake generated .config, they
>> are quite similar, but the CONFIG_UNION_FS=y line magically shows up.
>> I'm wondering where it comes from and how to disable it.
>
> CONFIG_UNION_FS is being enabled by the standard kernel (and all
> kernels that inherit it). Since you are based on that kernel, you
> get the option enabled.
>
>>
>> I can do a bitbake -c menuconfig virtual/kernel and eliminate that
>> option giving me the kernel I want, but those changes are gone after a
>> bitbake -c cleansstate ...
>
> Have you tried putting
>
> # CONFIG_UNION_FS is not set
>
> in your defconfig ? That should disable it.
>
I did try that, but that did not disable it.
So after much pain and thrashing about to figure things out, now I see
that in the standard-nocfg.scc file, the unionfs feature is set. This
file is found in the following path: tmp/work/..
../linux/meta/cfg/kernel-cache/ktypes/standard/ directory.
My current burning question is: Where is does this file come from? It
does not seem to be part of the kernel git repository. I can changes
this file and affect the kernel build, but again, those changes are
transitory and do not persist after cleaning.
Thanks,
Brian
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Magic kernel config option.
2013-01-02 21:11 Magic kernel config option Brian Smucker
@ 2013-01-02 21:12 ` Bruce Ashfield
2013-01-02 21:47 ` Brian Smucker
0 siblings, 1 reply; 8+ messages in thread
From: Bruce Ashfield @ 2013-01-02 21:12 UTC (permalink / raw)
To: Brian Smucker; +Cc: yocto@yoctoproject.org
On 13-01-02 04:11 PM, Brian Smucker wrote:
> On 1/2/2013 10:06 AM, Bruce Ashfield wrote:
> > On 12-12-24 02:59 PM, Brian Smucker wrote:
> >> Hi,
> >>
> >
> > Catching up on email from the holidays. Did you ever get an answer
> > to this ?
> Not yet, resumed my quest today.
>
> >> I'm a yocto mostly-newbie, trying to find my way. I have a custom
> layer
> >> that I am using to build a kernel. The layer right now consists of a
> few
> >> kernel patches and a defconfig and is based on the standard kernel
> >> otherwise.
> >>
> >> When I do a diff on my defconfig and the bitbake generated .config,
> they
> >> are quite similar, but the CONFIG_UNION_FS=y line magically shows up.
> >> I'm wondering where it comes from and how to disable it.
> >
> > CONFIG_UNION_FS is being enabled by the standard kernel (and all
> > kernels that inherit it). Since you are based on that kernel, you
> > get the option enabled.
> >
> >>
> >> I can do a bitbake -c menuconfig virtual/kernel and eliminate that
> >> option giving me the kernel I want, but those changes are gone after a
> >> bitbake -c cleansstate ...
> >
> > Have you tried putting
> >
> > # CONFIG_UNION_FS is not set
> >
> > in your defconfig ? That should disable it.
> >
> I did try that, but that did not disable it.
Hmmm. It worked here. I'll run another test shortly (I'm working on
3.8-rc1 at the moment).
>
> So after much pain and thrashing about to figure things out, now I see
> that in the standard-nocfg.scc file, the unionfs feature is set. This
> file is found in the following path: tmp/work/..
> ../linux/meta/cfg/kernel-cache/ktypes/standard/ directory.
>
> My current burning question is: Where is does this file come from? It
> does not seem to be part of the kernel git repository. I can changes
> this file and affect the kernel build, but again, those changes are
> transitory and do not persist after cleaning.
It's from the meta branch of the kernel git repository. Those
are all the fragments that are used to construct and configure
the kernel. Part of the build process makes them available to the
configuration phase.
As something else to try, call your file <foo>.cfg and add it to the
SRC_URI the same way you added the defconfig. defconfig's get special
processing, calling it <foo>.cfg will simply get your changes added
to the end of the build and they teka precedence. That being said, if
a feature with a Kconfig of the kernel has a "select UNIONFS" then you
can't override it with a config/defconfig option, you need to patch
the kernel.
If you send me your defconfig, I can run some test builds here.
Bruce
>
> Thanks,
>
> Brian
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Magic kernel config option.
2013-01-02 21:12 ` Bruce Ashfield
@ 2013-01-02 21:47 ` Brian Smucker
2013-01-02 22:15 ` Bruce Ashfield
0 siblings, 1 reply; 8+ messages in thread
From: Brian Smucker @ 2013-01-02 21:47 UTC (permalink / raw)
To: Bruce Ashfield, yocto@yoctoproject.org
On 1/2/2013 1:12 PM, Bruce Ashfield wrote:
> On 13-01-02 04:11 PM, Brian Smucker wrote:
>> On 1/2/2013 10:06 AM, Bruce Ashfield wrote:
>> > On 12-12-24 02:59 PM, Brian Smucker wrote:
>> >> Hi,
>> >>
>> >
>> > Catching up on email from the holidays. Did you ever get an answer
>> > to this ?
>> Not yet, resumed my quest today.
>>
>> >> I'm a yocto mostly-newbie, trying to find my way. I have a custom
>> layer
>> >> that I am using to build a kernel. The layer right now consists of a
>> few
>> >> kernel patches and a defconfig and is based on the standard kernel
>> >> otherwise.
>> >>
>> >> When I do a diff on my defconfig and the bitbake generated .config,
>> they
>> >> are quite similar, but the CONFIG_UNION_FS=y line magically shows
>> up.
>> >> I'm wondering where it comes from and how to disable it.
>> >
>> > CONFIG_UNION_FS is being enabled by the standard kernel (and all
>> > kernels that inherit it). Since you are based on that kernel, you
>> > get the option enabled.
>> >
>> >>
>> >> I can do a bitbake -c menuconfig virtual/kernel and eliminate that
>> >> option giving me the kernel I want, but those changes are gone
>> after a
>> >> bitbake -c cleansstate ...
>> >
>> > Have you tried putting
>> >
>> > # CONFIG_UNION_FS is not set
>> >
>> > in your defconfig ? That should disable it.
>> >
>> I did try that, but that did not disable it.
>
> Hmmm. It worked here. I'll run another test shortly (I'm working on
> 3.8-rc1 at the moment).
>
>>
>> So after much pain and thrashing about to figure things out, now I see
>> that in the standard-nocfg.scc file, the unionfs feature is set. This
>> file is found in the following path: tmp/work/..
>> ../linux/meta/cfg/kernel-cache/ktypes/standard/ directory.
>>
>> My current burning question is: Where is does this file come from? It
>> does not seem to be part of the kernel git repository. I can changes
>> this file and affect the kernel build, but again, those changes are
>> transitory and do not persist after cleaning.
>
> It's from the meta branch of the kernel git repository. Those
> are all the fragments that are used to construct and configure
> the kernel. Part of the build process makes them available to the
> configuration phase.
>
> As something else to try, call your file <foo>.cfg and add it to the
> SRC_URI the same way you added the defconfig. defconfig's get special
> processing, calling it <foo>.cfg will simply get your changes added
> to the end of the build and they teka precedence.
Tried your above suggestion, didn't seem to work.
So with a bit of further testing it looks like by the time the defconfig
and the <foo>.cfg are copied into the linux directory, the commented out
config option: # CONFIG_UNION_FS is not set
line is totally gone.
> That being said, if
> a feature with a Kconfig of the kernel has a "select UNIONFS" then you
> can't override it with a config/defconfig option, you need to patch
> the kernel.
Not sure what you are saying here. If you mean that the unionfs kernel
option is required by another selected kernel config option, I'm pretty
sure that's not the case. I can bitbake -c menuconfig virtual/kernel
and merely deselect the unionfs option and the kernel is good.
Brian
> If you send me your defconfig, I can run some test builds here.
>
> Bruce
>
>
>
>
>>
>> Thanks,
>>
>> Brian
>>
>>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Magic kernel config option.
2013-01-02 21:47 ` Brian Smucker
@ 2013-01-02 22:15 ` Bruce Ashfield
2013-01-02 22:43 ` Brian Smucker
0 siblings, 1 reply; 8+ messages in thread
From: Bruce Ashfield @ 2013-01-02 22:15 UTC (permalink / raw)
To: Brian Smucker; +Cc: yocto@yoctoproject.org
[-- Attachment #1: Type: text/plain, Size: 4821 bytes --]
On Wed, Jan 2, 2013 at 4:47 PM, Brian Smucker <bds@bsmucker.eu.org> wrote:
> On 1/2/2013 1:12 PM, Bruce Ashfield wrote:
>
>> On 13-01-02 04:11 PM, Brian Smucker wrote:
>>
>>> On 1/2/2013 10:06 AM, Bruce Ashfield wrote:
>>> > On 12-12-24 02:59 PM, Brian Smucker wrote:
>>> >> Hi,
>>> >>
>>> >
>>> > Catching up on email from the holidays. Did you ever get an answer
>>> > to this ?
>>> Not yet, resumed my quest today.
>>>
>>> >> I'm a yocto mostly-newbie, trying to find my way. I have a custom
>>> layer
>>> >> that I am using to build a kernel. The layer right now consists of a
>>> few
>>> >> kernel patches and a defconfig and is based on the standard kernel
>>> >> otherwise.
>>> >>
>>> >> When I do a diff on my defconfig and the bitbake generated .config,
>>> they
>>> >> are quite similar, but the CONFIG_UNION_FS=y line magically shows up.
>>> >> I'm wondering where it comes from and how to disable it.
>>> >
>>> > CONFIG_UNION_FS is being enabled by the standard kernel (and all
>>> > kernels that inherit it). Since you are based on that kernel, you
>>> > get the option enabled.
>>> >
>>> >>
>>> >> I can do a bitbake -c menuconfig virtual/kernel and eliminate that
>>> >> option giving me the kernel I want, but those changes are gone after
>>> a
>>> >> bitbake -c cleansstate ...
>>> >
>>> > Have you tried putting
>>> >
>>> > # CONFIG_UNION_FS is not set
>>> >
>>> > in your defconfig ? That should disable it.
>>> >
>>> I did try that, but that did not disable it.
>>>
>>
>> Hmmm. It worked here. I'll run another test shortly (I'm working on
>> 3.8-rc1 at the moment).
>>
>>
>>> So after much pain and thrashing about to figure things out, now I see
>>> that in the standard-nocfg.scc file, the unionfs feature is set. This
>>> file is found in the following path: tmp/work/..
>>> ../linux/meta/cfg/kernel-**cache/ktypes/standard/ directory.
>>>
>>> My current burning question is: Where is does this file come from? It
>>> does not seem to be part of the kernel git repository. I can changes
>>> this file and affect the kernel build, but again, those changes are
>>> transitory and do not persist after cleaning.
>>>
>>
>> It's from the meta branch of the kernel git repository. Those
>> are all the fragments that are used to construct and configure
>> the kernel. Part of the build process makes them available to the
>> configuration phase.
>>
>> As something else to try, call your file <foo>.cfg and add it to the
>> SRC_URI the same way you added the defconfig. defconfig's get special
>> processing, calling it <foo>.cfg will simply get your changes added
>> to the end of the build and they teka precedence.
>>
>
> Tried your above suggestion, didn't seem to work.
>
> So with a bit of further testing it looks like by the time the defconfig
> and the <foo>.cfg are copied into the linux directory, the commented out
> config option: # CONFIG_UNION_FS is not set
> line is totally gone.
>
>
Interesting .. and not really possible if you are talking about the version
in $WORKDIR (i.e
the directory above the linux/ source directory). Those are straight copies
from your
layer, with zero processing. Same with the copy within the linux/meta/cfg/*
directory
structure, they are straight copies and are only processed after being
ordered and
concatenated.
>
>
> That being said, if
>> a feature with a Kconfig of the kernel has a "select UNIONFS" then you
>> can't override it with a config/defconfig option, you need to patch
>> the kernel.
>>
> Not sure what you are saying here. If you mean that the unionfs kernel
> option is required by another selected kernel config option, I'm pretty
> sure that's not the case. I can bitbake -c menuconfig virtual/kernel and
> merely deselect the unionfs option and the kernel is good.
>
>
I can't see your source tree, so it was always an option. I know it
definitely isn't
the case in the linux-yocto tree. But the ability to deselect it in
menuconfig isn't
contingent on something else not selecting it from within another Kconfig.
Again, if you send me your defconfig and local.conf changes (for the BSP),
I'll
run a kernel configuration test and be able to easily tell you what is
happening.
Cheers,
Bruce
>
> Brian
>
>
>
>
>
> If you send me your defconfig, I can run some test builds here.
>>
>> Bruce
>>
>>
>>
>>
>>
>>> Thanks,
>>>
>>> Brian
>>>
>>>
>>>
>>
> ______________________________**_________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
[-- Attachment #2: Type: text/html, Size: 7005 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Magic kernel config option.
2013-01-02 22:15 ` Bruce Ashfield
@ 2013-01-02 22:43 ` Brian Smucker
2013-01-03 1:28 ` Bruce Ashfield
0 siblings, 1 reply; 8+ messages in thread
From: Brian Smucker @ 2013-01-02 22:43 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: yocto@yoctoproject.org
[-- Attachment #1: Type: text/plain, Size: 6360 bytes --]
I take everything back. The entry in the defconfig did the trick. My
problem was that the recipe was grabbing its defconfig from the wrong
directory, costing me much confusion.
So sorry for the false alarm. Thanks again for your help. When you
said the defconfig was a straight copy, the light finally dawned that
there was something else going on.
The silver lining to all this thrashing around for me was the fact that
I do understand the kernel bitbake process much better.
Brian
On 1/2/2013 2:15 PM, Bruce Ashfield wrote:
>
>
>
> On Wed, Jan 2, 2013 at 4:47 PM, Brian Smucker <bds@bsmucker.eu.org
> <mailto:bds@bsmucker.eu.org>> wrote:
>
> On 1/2/2013 1:12 PM, Bruce Ashfield wrote:
>
> On 13-01-02 04:11 PM, Brian Smucker wrote:
>
> On 1/2/2013 10:06 AM, Bruce Ashfield wrote:
> > On 12-12-24 02:59 PM, Brian Smucker wrote:
> >> Hi,
> >>
> >
> > Catching up on email from the holidays. Did you ever
> get an answer
> > to this ?
> Not yet, resumed my quest today.
>
> >> I'm a yocto mostly-newbie, trying to find my way. I
> have a custom
> layer
> >> that I am using to build a kernel. The layer right now
> consists of a
> few
> >> kernel patches and a defconfig and is based on the
> standard kernel
> >> otherwise.
> >>
> >> When I do a diff on my defconfig and the bitbake
> generated .config,
> they
> >> are quite similar, but the CONFIG_UNION_FS=y line
> magically shows up.
> >> I'm wondering where it comes from and how to disable it.
> >
> > CONFIG_UNION_FS is being enabled by the standard kernel
> (and all
> > kernels that inherit it). Since you are based on that
> kernel, you
> > get the option enabled.
> >
> >>
> >> I can do a bitbake -c menuconfig virtual/kernel and
> eliminate that
> >> option giving me the kernel I want, but those changes
> are gone after a
> >> bitbake -c cleansstate ...
> >
> > Have you tried putting
> >
> > # CONFIG_UNION_FS is not set
> >
> > in your defconfig ? That should disable it.
> >
> I did try that, but that did not disable it.
>
>
> Hmmm. It worked here. I'll run another test shortly (I'm
> working on
> 3.8-rc1 at the moment).
>
>
> So after much pain and thrashing about to figure things
> out, now I see
> that in the standard-nocfg.scc file, the unionfs feature
> is set. This
> file is found in the following path: tmp/work/..
> ../linux/meta/cfg/kernel-cache/ktypes/standard/ directory.
>
> My current burning question is: Where is does this file
> come from? It
> does not seem to be part of the kernel git repository. I
> can changes
> this file and affect the kernel build, but again, those
> changes are
> transitory and do not persist after cleaning.
>
>
> It's from the meta branch of the kernel git repository. Those
> are all the fragments that are used to construct and configure
> the kernel. Part of the build process makes them available to the
> configuration phase.
>
> As something else to try, call your file <foo>.cfg and add it
> to the
> SRC_URI the same way you added the defconfig. defconfig's get
> special
> processing, calling it <foo>.cfg will simply get your changes
> added
> to the end of the build and they teka precedence.
>
>
> Tried your above suggestion, didn't seem to work.
>
> So with a bit of further testing it looks like by the time the
> defconfig and the <foo>.cfg are copied into the linux directory,
> the commented out config option: # CONFIG_UNION_FS is not set
> line is totally gone.
>
>
> Interesting .. and not really possible if you are talking about the
> version in $WORKDIR (i.e
> the directory above the linux/ source directory). Those are straight
> copies from your
> layer, with zero processing. Same with the copy within the
> linux/meta/cfg/* directory
> structure, they are straight copies and are only processed after being
> ordered and
> concatenated.
>
>
>
> That being said, if
> a feature with a Kconfig of the kernel has a "select UNIONFS"
> then you
> can't override it with a config/defconfig option, you need to
> patch
> the kernel.
>
> Not sure what you are saying here. If you mean that the unionfs
> kernel option is required by another selected kernel config
> option, I'm pretty sure that's not the case. I can bitbake -c
> menuconfig virtual/kernel and merely deselect the unionfs option
> and the kernel is good.
>
>
> I can't see your source tree, so it was always an option. I know it
> definitely isn't
> the case in the linux-yocto tree. But the ability to deselect it in
> menuconfig isn't
> contingent on something else not selecting it from within another Kconfig.
>
> Again, if you send me your defconfig and local.conf changes (for the
> BSP), I'll
> run a kernel configuration test and be able to easily tell you what is
> happening.
>
> Cheers,
>
> Bruce
>
>
> Brian
>
>
>
>
>
> If you send me your defconfig, I can run some test builds here.
>
> Bruce
>
>
>
>
>
> Thanks,
>
> Brian
>
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
[-- Attachment #2: Type: text/html, Size: 12476 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Magic kernel config option.
2013-01-02 22:43 ` Brian Smucker
@ 2013-01-03 1:28 ` Bruce Ashfield
0 siblings, 0 replies; 8+ messages in thread
From: Bruce Ashfield @ 2013-01-03 1:28 UTC (permalink / raw)
To: Brian Smucker; +Cc: yocto@yoctoproject.org
On 13-01-02 5:43 PM, Brian Smucker wrote:
> I take everything back. The entry in the defconfig did the trick. My
> problem was that the recipe was grabbing its defconfig from the wrong
> directory, costing me much confusion.
>
> So sorry for the false alarm. Thanks again for your help. When you said
> the defconfig was a straight copy, the light finally dawned that there
> was something else going on.
Aha! That is good news. Thanks for following up.
>
> The silver lining to all this thrashing around for me was the fact that
> I do understand the kernel bitbake process much better.
:) Always a good thing.
Bruce
>
> Brian
>
> On 1/2/2013 2:15 PM, Bruce Ashfield wrote:
>>
>>
>>
>> On Wed, Jan 2, 2013 at 4:47 PM, Brian Smucker <bds@bsmucker.eu.org
>> <mailto:bds@bsmucker.eu.org>> wrote:
>>
>> On 1/2/2013 1:12 PM, Bruce Ashfield wrote:
>>
>> On 13-01-02 04:11 PM, Brian Smucker wrote:
>>
>> On 1/2/2013 10:06 AM, Bruce Ashfield wrote:
>> > On 12-12-24 02:59 PM, Brian Smucker wrote:
>> >> Hi,
>> >>
>> >
>> > Catching up on email from the holidays. Did you ever get
>> an answer
>> > to this ?
>> Not yet, resumed my quest today.
>>
>> >> I'm a yocto mostly-newbie, trying to find my way. I
>> have a custom
>> layer
>> >> that I am using to build a kernel. The layer right now
>> consists of a
>> few
>> >> kernel patches and a defconfig and is based on the
>> standard kernel
>> >> otherwise.
>> >>
>> >> When I do a diff on my defconfig and the bitbake
>> generated .config,
>> they
>> >> are quite similar, but the CONFIG_UNION_FS=y line
>> magically shows up.
>> >> I'm wondering where it comes from and how to disable it.
>> >
>> > CONFIG_UNION_FS is being enabled by the standard kernel
>> (and all
>> > kernels that inherit it). Since you are based on that
>> kernel, you
>> > get the option enabled.
>> >
>> >>
>> >> I can do a bitbake -c menuconfig virtual/kernel and
>> eliminate that
>> >> option giving me the kernel I want, but those changes
>> are gone after a
>> >> bitbake -c cleansstate ...
>> >
>> > Have you tried putting
>> >
>> > # CONFIG_UNION_FS is not set
>> >
>> > in your defconfig ? That should disable it.
>> >
>> I did try that, but that did not disable it.
>>
>>
>> Hmmm. It worked here. I'll run another test shortly (I'm
>> working on
>> 3.8-rc1 at the moment).
>>
>>
>> So after much pain and thrashing about to figure things
>> out, now I see
>> that in the standard-nocfg.scc file, the unionfs feature
>> is set. This
>> file is found in the following path: tmp/work/..
>> ../linux/meta/cfg/kernel-cache/ktypes/standard/ directory.
>>
>> My current burning question is: Where is does this file
>> come from? It
>> does not seem to be part of the kernel git repository. I
>> can changes
>> this file and affect the kernel build, but again, those
>> changes are
>> transitory and do not persist after cleaning.
>>
>>
>> It's from the meta branch of the kernel git repository. Those
>> are all the fragments that are used to construct and configure
>> the kernel. Part of the build process makes them available to the
>> configuration phase.
>>
>> As something else to try, call your file <foo>.cfg and add it
>> to the
>> SRC_URI the same way you added the defconfig. defconfig's get
>> special
>> processing, calling it <foo>.cfg will simply get your changes
>> added
>> to the end of the build and they teka precedence.
>>
>>
>> Tried your above suggestion, didn't seem to work.
>>
>> So with a bit of further testing it looks like by the time the
>> defconfig and the <foo>.cfg are copied into the linux directory,
>> the commented out config option: # CONFIG_UNION_FS is not set
>> line is totally gone.
>>
>>
>> Interesting .. and not really possible if you are talking about the
>> version in $WORKDIR (i.e
>> the directory above the linux/ source directory). Those are straight
>> copies from your
>> layer, with zero processing. Same with the copy within the
>> linux/meta/cfg/* directory
>> structure, they are straight copies and are only processed after being
>> ordered and
>> concatenated.
>>
>>
>>
>> That being said, if
>> a feature with a Kconfig of the kernel has a "select UNIONFS"
>> then you
>> can't override it with a config/defconfig option, you need to
>> patch
>> the kernel.
>>
>> Not sure what you are saying here. If you mean that the unionfs
>> kernel option is required by another selected kernel config
>> option, I'm pretty sure that's not the case. I can bitbake -c
>> menuconfig virtual/kernel and merely deselect the unionfs option
>> and the kernel is good.
>>
>>
>> I can't see your source tree, so it was always an option. I know it
>> definitely isn't
>> the case in the linux-yocto tree. But the ability to deselect it in
>> menuconfig isn't
>> contingent on something else not selecting it from within another Kconfig.
>>
>> Again, if you send me your defconfig and local.conf changes (for the
>> BSP), I'll
>> run a kernel configuration test and be able to easily tell you what is
>> happening.
>>
>> Cheers,
>>
>> Bruce
>>
>>
>> Brian
>>
>>
>>
>>
>>
>> If you send me your defconfig, I can run some test builds here.
>>
>> Bruce
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Brian
>>
>>
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 8+ messages in thread
* Magic kernel config option.
@ 2012-12-24 19:59 Brian Smucker
2013-01-02 18:06 ` Bruce Ashfield
0 siblings, 1 reply; 8+ messages in thread
From: Brian Smucker @ 2012-12-24 19:59 UTC (permalink / raw)
To: yocto@yoctoproject.org
Hi,
I'm a yocto mostly-newbie, trying to find my way. I have a custom layer
that I am using to build a kernel. The layer right now consists of a few
kernel patches and a defconfig and is based on the standard kernel
otherwise.
When I do a diff on my defconfig and the bitbake generated .config, they
are quite similar, but the CONFIG_UNION_FS=y line magically shows up.
I'm wondering where it comes from and how to disable it.
I can do a bitbake -c menuconfig virtual/kernel and eliminate that
option giving me the kernel I want, but those changes are gone after a
bitbake -c cleansstate ...
Could someone give me some help about where to go from here?
Thanks,
Brian
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Magic kernel config option.
2012-12-24 19:59 Brian Smucker
@ 2013-01-02 18:06 ` Bruce Ashfield
0 siblings, 0 replies; 8+ messages in thread
From: Bruce Ashfield @ 2013-01-02 18:06 UTC (permalink / raw)
To: Brian Smucker; +Cc: yocto@yoctoproject.org
On 12-12-24 02:59 PM, Brian Smucker wrote:
> Hi,
>
Catching up on email from the holidays. Did you ever get an answer
to this ?
> I'm a yocto mostly-newbie, trying to find my way. I have a custom layer
> that I am using to build a kernel. The layer right now consists of a few
> kernel patches and a defconfig and is based on the standard kernel
> otherwise.
>
> When I do a diff on my defconfig and the bitbake generated .config, they
> are quite similar, but the CONFIG_UNION_FS=y line magically shows up.
> I'm wondering where it comes from and how to disable it.
CONFIG_UNION_FS is being enabled by the standard kernel (and all
kernels that inherit it). Since you are based on that kernel, you
get the option enabled.
>
> I can do a bitbake -c menuconfig virtual/kernel and eliminate that
> option giving me the kernel I want, but those changes are gone after a
> bitbake -c cleansstate ...
Have you tried putting
# CONFIG_UNION_FS is not set
in your defconfig ? That should disable it.
Bruce
>
> Could someone give me some help about where to go from here?
>
> Thanks,
> Brian
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-01-03 1:28 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-02 21:11 Magic kernel config option Brian Smucker
2013-01-02 21:12 ` Bruce Ashfield
2013-01-02 21:47 ` Brian Smucker
2013-01-02 22:15 ` Bruce Ashfield
2013-01-02 22:43 ` Brian Smucker
2013-01-03 1:28 ` Bruce Ashfield
-- strict thread matches above, loose matches on Subject: below --
2012-12-24 19:59 Brian Smucker
2013-01-02 18:06 ` Bruce Ashfield
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.