linux-kernel - Re: RFC: kconfig select warnings bogus?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 May 2007 20:23:27 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Stefan Richter" <stefanr@...6.in-berlin.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"Roman Zippel" <zippel@...ux-m68k.org>,
	"Kumar Gala" <galak@...nel.crashing.org>,
	"Simon Horman" <horms@...ge.net.au>,
	"Adrian Bunk" <bunk@...sta.de>, "Sam Ravnborg" <sam@...nborg.org>
Subject: Re: RFC: kconfig select warnings bogus?

On 5/20/07, Stefan Richter <stefanr@...6.in-berlin.de> wrote:

[ I was wondering whether to reply or not (this has become sort of a
a dead thread and subsumed by Sam's proposal to scan all Kconfig
files, but still) ... ]

> Satyam Sharma wrote:
> > On 5/20/07, Stefan Richter <stefanr@...6.in-berlin.de> wrote:
> >> config A
> >>         bool-or-tristate "option A"
> >>         depends on !PLATFORM_X || HELPER_N_ON_PLATFORM_X
> >
> > ??? I didn't get this entry,
>
> "A is available if N is there or if it's a platform other than X."
>
> That would be adequate if N is only present and required on platform X.

Umm, if A requires helper code N (which is available only on platform X),
then why/how do we want A to depend on platforms _other_ than X?
That "||" OR there is totally incorrect, because it allows A to be selected
even _without_ N, which won't even allow A to build properly! Remember,
something "depends on" or wishes to "select" some other thing only if
it *reuses code exported* by the dependency.

Beginning to wonder if you even _understood_ the problem that was
being solved there ... I seriously recommend that if / when you _really_
think you have some good idea to solve some problem, then submitting
a working patch is invariably always better (and causes lesser noise :-)

> > can you give a solid example
>
> Nothing exactly of this sort, but compare for example kernel/power/Kconfig:
>
> config SOFTWARE_SUSPEND
>         bool "Software Suspend (Hibernation)"
>         depends on PM && SWAP && (((X86 || PPC64_SWSUSP) &&
>                 (!SMP || SUSPEND_SMP)) || ((FRV || PPC32) && !SMP))
>
> Of course this could be written in a clearer fashion, for example as
>
>         depends on PM
>         depends on SWAP
>         depends on (X86 && !SMP) ||
>                    (X86 && SUSPEND_SMP) ||
>                    (PPC64_SWSUSP && !SMP) ||
>                    (PPC64_SWSUSP && SUSPEND_SMP) ||
>                    (FRV   && !SMP) ||
>                    (PPC32 && !SMP)

Ok, so perhaps you actually meant X && N_ON_X above. But your
suggestion is _still_ wrong. Using "depends on" instead of "select" does
get rid of the warnings, but that conversion would *not* maintain current
behaviour (that of the config option being visible and automatically
selecting its dependency -- "default y if ..." otoh does preserve current
behaviour and hence _can_ replace select).

This is precisely what Trent meant that the kind of dependencies you
were suggesting in your mails can't be "select"ed in the first place.

Anyway, I've had enough of this thread. The patch that I had sent was
a 7-line *triviality* that merely (1) preserved current behaviour, (2) did
not cause _any_ build problems, and (3) got rid of bogus warnings in
a way that was completely standard when dealing with arch/.../Kconfig's
and better than the initial suggestion by Sam. Can't quite understand
how this became such a fiasco that ruined my Sunday :-)

Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/