[poky] How to build a kernel using menuconfig

[Gary Thomas]

On 2011-09-28 07:35, Gary Thomas wrote:
> On 2011-09-28 07:15, Richard Purdie wrote:
>> On Wed, 2011-09-28 at 05:33 -0600, Gary Thomas wrote:
>>> On 2011-09-27 21:45, Darren Hart wrote:
>>>>
>>>>
>>>> On 09/26/2011 06:45 AM, Gary Thomas wrote:
>>>>> I'm working with a recent Poky checkout:
>>>>> meta-yocto = "master:7a0cbe6b0e5185aebabedc515b427994bc2a15dc"
>>>>>
>>>>> I used to be able to do this:
>>>>> % bitbake<some-image>
>>>>> This step builds everything, including the kernel
>>>>> % bitbake virtual/kernel -c menuconfig
>>>>> Adjust some settings
>>>>> % bitbake virtual/kernel -c compile -f
>>>>> % bitbake virtual/kernel
>>>>> Rebuild my image with the new kernel included
>>>>> % bitbake<some-image>
>>>>>
>>>>> In the past, this would let me adjust some kernel settings, e.g. add a new
>>>>> module, then rebuild it and later add this to an image. Sadly, when I run
>>>>> through these steps with the current master, the new kernel gets compiled
>>>>> (because I used -f), but not packaged.
>>>>>
>>>>> The only thing I've done differently, save updating master, is my build
>>>>> today includes
>>>>> INHERIT += "rm_work"
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>> How can I build the kernel and make these in-tree adjustments like I used to?
>>>>> I do this to figure out what kernel settings to set/save for my final packaging.
>>>>
>>>>
>>>> Yeah, this is standard kernel devel workflow. I typically use the kernel
>>>> recipe name directly, but otherwise my process is the same. What happens
>>>> now when you run "bitbake virtual/kernel" after the compile -f ?
>>>>
>>>
>>> As indicated above, nothing. If I remove rm_work from my configuration
>>> and then rebuild the kernel, it works as expected.
>>
>> It sounds like there is a bad interaction between rm_work and this set
>> of steps. I can kind of see why, rm_work promotes the stamp files to
>> setscene ones (so the same as if a sstate build was made). Nothing in
>> the above steps would actually remove the setscene stamps so bitbake
>> sees them and assumes everything is still valid.
>>
>> If you did a bitbake -c package -f virtual/kernel then I suspect it
>> would actually sort itself out. Off the top of my head I can't see a way
>> to fix this in any straightforward way :/.
>
> My inclination is to just not allow rm_work for kernel recipes. Perhaps
> it's possible to filter out rm_work for this recipe like this?
> INHERIT := "${@oe_filter_out('rm_work', '${INHERIT}', d)}"
> Note: I've not tried it, just a thought.

Sadly, this doesn't work.  For now, I'll just note that rm_work is
incompatible with kernel fiddling :-(

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------