From: "Satyam Sharma" <satyam.sharma@gmail.com>
To: "Stefan Richter" <stefanr@s5r6.in-berlin.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Roman Zippel" <zippel@linux-m68k.org>,
"Kumar Gala" <galak@kernel.crashing.org>,
"Simon Horman" <horms@verge.net.au>,
"Adrian Bunk" <bunk@stusta.de>, "Sam Ravnborg" <sam@ravnborg.org>
Subject: Re: RFC: kconfig select warnings bogus?
Date: Tue, 22 May 2007 20:23:27 +0530 [thread overview]
Message-ID: <a781481a0705220753g25bb0dd8u33bbf8ddaf00f50c@mail.gmail.com> (raw)
In-Reply-To: <46505DBD.5010005@s5r6.in-berlin.de>
On 5/20/07, Stefan Richter <stefanr@s5r6.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@s5r6.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
next prev parent reply other threads:[~2007-05-22 14:53 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-19 15:15 Sam Ravnborg
2007-05-19 18:09 ` Andrew Morton
2007-05-19 22:17 ` Satyam Sharma
2007-05-19 22:49 ` Satyam Sharma
2007-05-19 23:09 ` Adrian Bunk
2007-05-19 23:17 ` Satyam Sharma
2007-05-19 23:25 ` Adrian Bunk
2007-05-19 23:36 ` Satyam Sharma
2007-05-19 23:41 ` Satyam Sharma
2007-05-19 23:51 ` Adrian Bunk
2007-05-20 0:02 ` Satyam Sharma
2007-05-19 23:48 ` Adrian Bunk
2007-05-19 23:55 ` Satyam Sharma
2007-05-20 0:13 ` Adrian Bunk
2007-05-20 0:19 ` Satyam Sharma
2007-05-20 9:52 ` Trent Piepho
2007-05-20 10:58 ` Stefan Richter
2007-05-20 11:23 ` Trent Piepho
2007-05-20 11:44 ` Stefan Richter
2007-05-20 19:57 ` Trent Piepho
2007-05-20 20:12 ` Stefan Richter
2007-05-20 20:41 ` Trent Piepho
2007-05-22 15:13 ` Satyam Sharma
2007-05-20 18:30 ` Adrian Bunk
2007-05-20 0:46 ` Stefan Richter
2007-05-20 0:53 ` Satyam Sharma
2007-05-20 1:04 ` Satyam Sharma
2007-05-20 8:31 ` Stefan Richter
2007-05-20 11:38 ` Satyam Sharma
2007-05-20 11:47 ` Stefan Richter
2007-05-20 11:57 ` Satyam Sharma
2007-05-20 13:09 ` Stefan Richter
2007-05-20 13:50 ` Satyam Sharma
2007-05-20 14:39 ` Stefan Richter
2007-05-22 14:53 ` Satyam Sharma [this message]
2007-05-22 17:03 ` Stefan Richter
2007-05-22 17:13 ` Satyam Sharma
2007-05-22 17:38 ` Stefan Richter
2007-05-22 17:46 ` Satyam Sharma
2007-05-22 17:54 ` Stefan Richter
2007-05-22 17:59 ` Satyam Sharma
2007-05-20 18:23 ` Adrian Bunk
2007-05-19 23:05 ` Adrian Bunk
2007-05-19 23:17 ` Satyam Sharma
2007-05-19 23:21 ` Satyam Sharma
2007-05-19 23:29 ` Adrian Bunk
2007-05-19 23:32 ` Satyam Sharma
2007-05-19 23:23 ` Adrian Bunk
2007-05-19 23:22 ` Andrew Morton
2007-05-20 0:02 ` Adrian Bunk
2007-05-20 0:11 ` Satyam Sharma
2007-05-20 9:43 ` Russell King
2007-05-20 9:40 ` Russell King
2007-05-20 10:17 ` Sam Ravnborg
2007-05-20 11:07 ` Geert Uytterhoeven
2007-05-21 0:25 ` Roman Zippel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a781481a0705220753g25bb0dd8u33bbf8ddaf00f50c@mail.gmail.com \
--to=satyam.sharma@gmail.com \
--cc=bunk@stusta.de \
--cc=galak@kernel.crashing.org \
--cc=horms@verge.net.au \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=stefanr@s5r6.in-berlin.de \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®