On Thu, 2011-09-01 at 20:32 -0400, Arnaud Lacombe wrote:

Hi,

On Sat, Aug 27, 2011 at 2:06 AM, Arnaud Lacombe [off-list ref] wrote:

quoted

Hi,

On Fri, Aug 26, 2011 at 1:00 PM, Randy Dunlap [off-list ref] wrote:

quoted

On Fri, 26 Aug 2011 08:39:02 -0400 Mimi Zohar wrote:

quoted

On Tue, 2011-08-23 at 22:10 -0400, Arnaud Lacombe wrote:

quoted

Hi,

On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap [off-list ref] wrote:

quoted

I think that you are going to need to do something like Arnaud suggested
and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
unless you can convince someone that this is a kconfig bug.

dammit... I guess there is...

If you consider the following Kconfig:

config MOD
        bool
        default y
        option modules

config EXPERIMENTAL
        bool
        default y

menuconfig A
        tristate "A"
        depends on EXPERIMENTAL

config B
        bool "B"

config B0
        bool

config C
        tristate "C"
        depends on B

config C0
        tristate

config D
        boolean "D"
        depends on A && B
        select C
        select C0

config E
        tristate "E"

config F
        tristate "F"
        select E

B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
(TCG_TPM) allows to set D (EVM), which will select (C). Now,
menuconfig highlight the problem very well. Proceeding as following
A=m, B=y, C=m, E=y, F=y, we ends up having:

 <M> A  --->
 [*] B
 {M} C
 [*] D
 -*- E
 <*> F

which translate in the following config:

CONFIG_MOD=y
CONFIG_EXPERIMENTAL=y
CONFIG_A=m
CONFIG_B=y
CONFIG_C=m
CONFIG_C0=m
CONFIG_D=y
CONFIG_E=y
CONFIG_F=y

I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
If you remove D's dependency on 'A', everything works as expected. So
it would seem direct dependency state influence the state of reverse
dependencies...

Will have a look...

 - Arnaud

Thanks for looking into this!  Instead of changing 'TCG_TPM' to
'TCG_TPM=y', the dependency should be on 'TRUSTED_KEYS=y'.  Then when
I've refactored ENCRYPTED_KEYS, removing the ENCRYPTED_KEYS dependency
on TRUSTED_KEYS, the EVM dependency would be '(TRUSTED_KEYS=y ||
TRUSTED_KEYS=n)'.  Do you want a temporary fix for now?

Yes, linux-next (randconfig) builds are still failing, so we need something
to prevent that.

you may want to try:

git://github.com/lacombar/linux-2.6.git master/kconfig/expr-woes

ping ?

 - Arnaud

I assume you want me to test using expr-woes, but I'm not how.  Could
you help me here a bit.

(Over the weekend I removed encrypted keys dependency on TCG_TPM.)

thanks,

Mimi

quoted

only the last commit is relevant to the problem, but depend on one
another to get <assert.h>. The rest aims at tidying the expr stuff.
I'm looking for regression it may have introduced.

Thanks,
 - Arnaud

ps: I'll most likely be AFK until sunday evening (to be conservative).

quoted

thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***