[wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Thu, 2015-05-07 at 22:14 +0200, Paul Bolle wrote:
> Tomorrow, after a (western European) night of sleep, I hope to explain
> why the error in dad's file makes sense. I'm not much of a teacher so I
> need a clear head to do that.

Let's start with mom's Kconfig file. It triggers
	error: recursive dependency detected!
	symbol GYM depends on ROCK_CLIMBING
	symbol ROCK_CLIMBING depends on LOCKER
	symbol LOCKER depends on GYM

Now you should realize that the kconfig tools have to answers questions
like these, for each (tristate) symbol:
	- must it be 'n'; or
	- can it be 'm'; or
	- can it be 'y'.

Take, for example: can GYM be 'y'? Since GYM depends on ROCK_CLIMBING,
it can only be 'y' if ROCK_CLIMBING is 'y' (both being tristate). And
ROCK_CLIMBING depends on LOCKER, so ROCK_CLIMBING can only be 'y' if
LOCKER is 'y' (ditto). And LOCKER, in its turn, depends on GYM, so it
can only be 'y', if GYM is 'y'.

But we can't say whether GYM is 'y' yet, as it can still be 'n', 'm', or
'y' for all we know. So we can't answer that question. Hence the
recursive dependency error. (There must be a term for this obvious
problem in formal logic, but I'm not trained in formal logic.)

On to dad's Kconfig file (which is your example, but simplified). That
triggers:
	error: recursive dependency detected!
	symbol GYM is selected by ROCK_CLIMBING
	symbol ROCK_CLIMBING depends on LOCKER
	symbol LOCKER depends on GYM

Let's try to determine whether GYM should be 'n'. Well, GYM is selected
by ROCK_CLIMBING so it cannot be 'n' if ROCK_CLIMBING is 'm' or 'y'. (If
ROCK_CLIMBING is 'm' it can be 'm' or 'y', but not 'n', and if
ROCK_CLIMBING is 'y' it must be 'y'.) Do we know whether ROCK_CLIMBING
should be 'n'? It should be 'n' only if LOCKER is 'n'. And LOCKER should
in its turn be 'n' if GYM is 'n'. But we don't know yet what GYM will
be. So, again, we can't answer this question. Recursive dependency
error!

The complicated error you ran into was
	error: recursive dependency detected!
	symbol CRYPTO is selected by SYSDATA_SIG
	symbol SYSDATA_SIG is selected by FIRMWARE_SIG
	symbol FIRMWARE_SIG depends on FW_LOADER
	symbol FW_LOADER is selected by CRYPTO_DEV_QAT
	symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO

I'm lazy, so I haven't gone through this error step by step. But I'm
sure it's just a complicated version of what I tried to explain in the
above two examples. But if you're unconvinced I'll try to go through
this error too.

Now I'm sure the point I'm trying to make can be made more convincingly
and more elegantly. But the thing is, I think, that given how "select"
works and how "depends on" works, some setups will trigger these errors.
One might wish that "select" or "depends on" behaved differently, but
with the thousands of Kconfig symbols now in use, that really looks
unfeasible.

(Now let's see how all the, mostly German, people trained in formal
logic that appear to care about the kconfig tools shoot holes in my
reasoning.)

Hope this helps,


Paul Bolle