Re: [PATCH] MIPS: Kconfig: Set default value for the "Kernel code model"

Re: [PATCH] MIPS: Kconfig: Set default value for the "Kernel code model"

[Ralf Baechle]

On Tue, Jun 11, 2013 at 10:52:16AM +0100, Markos Chandras wrote:

(Adding the kconfig maintainer and mailing list to cc.)

> Certain randconfigs may not select neither CONFIG_32BIT nor
> CONFIG_64BIT which can lead to build problems and to the following
> Kbuild warning:
> 
> .config:154:warning: symbol value '' invalid for PHYSICAL_START
> 
> Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
> Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>

Systems are supposed to set if they support 32 bit kernels and/or 64 bit
kernels in arch/mips/Kconfig.  The behaviour you're reporting happens
if the default system (which happens to be SGI_IP22) supports both
kernel models, that is SYS_SUPPORTS_32BIT_KERNEL and
SYS_SUPPORTS_64BIT_KERNEL are set.  Then "make randconfig" will generate
a .config with neiher CONFIG_32BIT nor CONFIG_64BIT set.

Just defaulting to CONFIG_32BIT as in your patch
http://patchwork.linux-mips.org/patch/5377/ isn't really a good solution
because for some platforms 32 bit kernels, for others 64 bit kernels are
preferred so I tried to implement something like

choice
        prompt "Kernel code model"
        default 32BIT if SYS_32BIT_KERNEL_PREFERRED
        default 64BIT if SYS_64BIT_KERNEL_PREFERRED

and have individual platforms set their preferred kernel variant.  And
I got more odd Kconfig behaviour, getting both choice values 32BIT and
64BIT set for some platforms.

Another variant that only uses a single auxilliary symbol,
SYS_64BIT_KERNEL_PREFERRED like this:

choice
        prompt "Kernel code model"
        default 32BIT if !SYS_64BIT_KERNEL_PREFERRED
        default 64BIT if SYS_64BIT_KERNEL_PREFERRED

still results in

CONFIG_32BIT=y
CONFIG_64BIT=y

So I'm not quite certain how to obtain the desired behaviour - but I appears
highly unobvious to buggy on kconfig's side.

Michal, can you shed some light?

  Ralf

Re: [PATCH] MIPS: Kconfig: Set default value for the "Kernel code model"

[Ralf Baechle]

Here's a simplified test case:

< --------- bite here --------- >
choice
	prompt "choice 1"

config FOO1
	bool "foo 1"

config FOO2
	bool "foo 2"
endchoice

choice
	prompt "frob"

config BAR
	bool "bar"
	depends on FOO2

endchoice
< --------- bite here --------- >

Save this to a file, then run:

  scripts/kconfig/conf --randconfig /tmp/xxx && cat .config

There will be two possible variants for generated .config files:

< --------- Variant 1 --------- >
CONFIG_FOO1=y
# CONFIG_FOO2 is not set
< --------- Variant 2 --------- >
# CONFIG_FOO1 is not set
# CONFIG_FOO2 is not set
< --------- End       --------- >

The intended third outcome which would be
< --------- doesn't happen ---- >
# CONFIG_FOO1 is not set
CONFIG_FOO2=y
< --------- End --------------- >

never gets generated.

Pretty much any tempering with this test case will change the behaviour.
For example removing the "depends on FOO2" line will result in the
behaviour of either CONFIG_FOO1 or CONFIG_FOO2 being set to y but never
none or both.  Other minor changes might result in both symbols getting
set.

  Ralf

Re: [PATCH] MIPS: Kconfig: Set default value for the "Kernel code model"

[Markos Chandras]

On 12 June 2013 12:20, Ralf Baechle <ralf@linux-mips.org> wrote:
> Here's a simplified test case:
>
> < --------- bite here --------- >
> choice
>         prompt "choice 1"
>
> config FOO1
>         bool "foo 1"
>
> config FOO2
>         bool "foo 2"
> endchoice
>
> choice
>         prompt "frob"
>
> config BAR
>         bool "bar"
>         depends on FOO2
>
> endchoice
> < --------- bite here --------- >
>
> Save this to a file, then run:
>
>   scripts/kconfig/conf --randconfig /tmp/xxx && cat .config
>
> There will be two possible variants for generated .config files:
>
> < --------- Variant 1 --------- >
> CONFIG_FOO1=y
> # CONFIG_FOO2 is not set
> < --------- Variant 2 --------- >
> # CONFIG_FOO1 is not set
> # CONFIG_FOO2 is not set
> < --------- End       --------- >
>
> The intended third outcome which would be
> < --------- doesn't happen ---- >
> # CONFIG_FOO1 is not set
> CONFIG_FOO2=y
> < --------- End --------------- >
>
> never gets generated.
>
> Pretty much any tempering with this test case will change the behaviour.
> For example removing the "depends on FOO2" line will result in the
> behaviour of either CONFIG_FOO1 or CONFIG_FOO2 being set to y but never
> none or both.  Other minor changes might result in both symbols getting
> set.
>
>   Ralf
>

Thanks for the testcase Ralf. My understanding is that if the 'choice'
symbol is available (meaning, all the dependencies are satisfied),
then one of the possible choices should always be selected. So
variant2 in the previous example seems wrong behavior to me.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang