menuconfig task for kernels

menuconfig task for kernels

[Przemyslaw Wesolek]

Hi,

today I decided to modify the kernel compiled by OE. Accidentally, in
the same time a person on IRC pointed out problems with that. After some
investigation we discovered that menuconfig task in kernels is somewhat
misleading, if not broken.

The order of tasks to do menuconfig is, more or less: fetch, patch,
menuconfig. It means that when menuconfig is run, there is no .config*
files in linux build dir, and generated .config is far different than
defconfig resulting from applying OE patches.

The order for correct configuring of Linux is: fetch, patch, configure,
so I tried:

  1. bitbake virtual/kernel -c configure
  2. bitbake virtual/kernel -c menuconfig
  3. bitbake virtual/kernel

and this allowed me to apply my local changes to OE-proposed .config.

Is this the "right" way to do? If so, maybe menuconfig should be added
as 'after do_configure', instead of 'after do_patch'?

Przemek

Re: menuconfig task for kernels

[Przemyslaw Wesolek]

> Is this the "right" way to do? If so, maybe menuconfig should be added
> as 'after do_configure', instead of 'after do_patch'?

Anyone?

Przemek

Re: menuconfig task for kernels

[Michael Smith]

Przemyslaw Wesolek wrote:
>> Is this the "right" way to do? If so, maybe menuconfig should be added
>> as 'after do_configure', instead of 'after do_patch'?
> 
> Anyone?

Hi Przemek,

I find if I'm configuring for a new machine, I need to do_patch, copy a 
"close" defconfig into place, run make menuconfig, and copy the .config 
back to the filesdir where it belongs. The menuconfig task doesn't save 
much, as you still have to copy the defconfigs around. I don't use the 
task for that reason, and maybe others are in the same boat.

I think you're right about the order, though; if you sent a patch, I 
would ack it, for what it's worth.

Mike

Re: menuconfig task for kernels

[Martin Jansa]

On Mon, Nov 09, 2009 at 10:40:36AM -0500, Michael Smith wrote:
> Przemyslaw Wesolek wrote:
> >>Is this the "right" way to do? If so, maybe menuconfig should be added
> >>as 'after do_configure', instead of 'after do_patch'?
> >
> >Anyone?
> 
> Hi Przemek,
> 
> I find if I'm configuring for a new machine, I need to do_patch,
> copy a "close" defconfig into place, run make menuconfig, and copy
> the .config back to the filesdir where it belongs. The menuconfig
> task doesn't save much, as you still have to copy the defconfigs
> around. I don't use the task for that reason, and maybe others are
> in the same boat.
> 
> I think you're right about the order, though; if you sent a patch, I
> would ack it, for what it's worth.
> 
> Mike
Hi,

From what I checked now in linux.inc, then you're right that
do_menuconfig is called just after do_patch, which seems wrong, because
in do_configure_prepend it prepares few lines to .config (like logo,
*abi, thumb) and then appends defconfig without conflicting lines.

If I need to enable some options temporary then I use
-c configure (for sane .config)
-c menuconfig (for temporary modification)
-c build 

But if you want to use menuconfig for updating defconfig used in OE tree
or default config in kernel (like arch/arm/configs/gta02_defconfig) then
do_configure phase would change some options you didn't want to touch
(as they can be OE specific, ie disabling deprecated sysfs paths for
${UDEV_GE_141}.

So 1st case is easily workarounded by user in current state.

2nd will be a bit more difficult if its moved to after do_configure
as you need to revert all changes automagically introduced in 
do_configure_prepend in menuconfig or replace .config with defconfig
between do_configure and do_menuconfig or just use load ../defconfig
option from menuconfig. (Hmm doesn't look more difficult now :))

Btw: haven't checked but if you use
-c menuconfig (create custom config)
-c build

isn't your custom .config rewritten in do_configure phase with defconfig
+ do_configure_prepend automagic?.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: menuconfig task for kernels

[Przemyslaw Wesolek]

Martin Jansa wrote:
> If I need to enable some options temporary then I use
> -c configure (for sane .config)
> -c menuconfig (for temporary modification)
> -c build 

This is exactly what I want to do, as a *user*.

> But if you want to use menuconfig for updating defconfig used in OE tree
> or default config in kernel (like arch/arm/configs/gta02_defconfig) then
> do_configure phase would change some options you didn't want to touch
> (as they can be OE specific, ie disabling deprecated sysfs paths for
> ${UDEV_GE_141}.

This is what -- I guess -- recipes *maintainers* do.

> 
> So 1st case is easily workarounded by user in current state.
> 

Agreed, with the exception that this is a path hard to find, without
looking into the recipes and classes. And this is not what all *users*
are competent to do.

> 2nd will be a bit more difficult if its moved to after do_configure
> as you need to revert all changes automagically introduced in 
> do_configure_prepend in menuconfig or replace .config with defconfig
> between do_configure and do_menuconfig or just use load ../defconfig
> option from menuconfig. (Hmm doesn't look more difficult now :))

I think of two possible solutions:

1. Add another task, which will do the same as 'menuconfig' now, and
change 'menuconfig' to run after 'configure'. This way, users can work
under assumptions of "least surprise" (in my terms, I agree, but I'm a
mere user, too).

2. Change 'configure' to operate on existing .config, if there is one;
this way 'menuconfig' and 'configure' can cooperate, although resulting
.config can have contradicting options selected and lead to errors (but
maybe 'make oldconfig' can point them out?).

I opt for 1., as 2. seems hard and risky.

> Btw: haven't checked but if you use
> -c menuconfig (create custom config)
> -c build
> 
> isn't your custom .config rewritten in do_configure phase with defconfig
> + do_configure_prepend automagic?.

Yes, it is overwritten with 'echo "" >path/to/.config' at the beginning
of do_configure.

Przemek

Re: menuconfig task for kernels

[Leon Woestenberg]

Hello,

On Thu, Nov 5, 2009 at 11:38 PM, Przemyslaw Wesolek
<przemyslaw.wesolek@cs.put.poznan.pl> wrote:
>
> The order of tasks to do menuconfig is, more or less: fetch, patch,
> menuconfig. It means that when menuconfig is run, there is no .config*
> files in linux build dir, and generated .config is far different than
> defconfig resulting from applying OE patches.
> [...]
> Is this the "right" way to do? If so, maybe menuconfig should be added
> as 'after do_configure', instead of 'after do_patch'?
>

Look in classes/kernel.bbclass, line ~221:

addtask menuconfig after do_patch

change it to:

addtask menuconfig after do_configure


and see if that helps.

I wonder if this can go upstream.


Regards,
-- 
Leon

Re: menuconfig task for kernels

[Otavio Salvador]

Hello,

On Tue, Nov 10, 2009 at 2:06 PM, Leon Woestenberg
<leon.woestenberg@gmail.com> wrote:
> Look in classes/kernel.bbclass, line ~221:
>
> addtask menuconfig after do_patch
>
> change it to:
>
> addtask menuconfig after do_configure
>
>
> and see if that helps.
>
> I wonder if this can go upstream.

After menuconfig the .config might be copied back to the recipe?

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: menuconfig task for kernels

[Leon Woestenberg]

Hello Otavio,

On Tue, Nov 10, 2009 at 6:05 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> Hello,
>
> On Tue, Nov 10, 2009 at 2:06 PM, Leon Woestenberg
> <leon.woestenberg@gmail.com> wrote:
>> Look in classes/kernel.bbclass, line ~221:
>>
>> addtask menuconfig after do_patch
>> change it to:
>> addtask menuconfig after do_configure
>>
>> I wonder if this can go upstream.
>
Any response to this idea?


> After menuconfig the .config might be copied back to the recipe?
>
That's a(n additional totally different) feature request.

I'ld rather fix things first, then add new features.


Regards,
-- 
Leon

Re: menuconfig task for kernels

[Przemyslaw Wesolek]

Leon Woestenberg wrote:
> Hello Otavio,
> 
> On Tue, Nov 10, 2009 at 6:05 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> Hello,
>>
>> On Tue, Nov 10, 2009 at 2:06 PM, Leon Woestenberg
>> <leon.woestenberg@gmail.com> wrote:
>>> Look in classes/kernel.bbclass, line ~221:
>>>
>>> addtask menuconfig after do_patch
>>> change it to:
>>> addtask menuconfig after do_configure
>>>
>>> I wonder if this can go upstream.
> Any response to this idea?

I support it. This is expected behavior from the casual user point of view.

Przemek