From: Miles Bader <miles@lsi.nec.co.jp>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Adrian Bunk <bunk@fs.tum.de>, linux-kernel@vger.kernel.org
Subject: Re: New kconfig: Please add define_*
Date: 22 Nov 2002 11:22:13 +0900 [thread overview]
Message-ID: <buon0o2fine.fsf@mcspd15.ucom.lsi.nec.co.jp> (raw)
In-Reply-To: <Pine.LNX.4.44.0211211740130.2113-100000@serv>
Roman Zippel <zippel@linux-m68k.org> writes:
> Also note that the role of the default has changed, a default cannot
> override a prompt anymore (it only provides a default value to the
> prompt). The define_* syntax might imply that this is possible, but it
> won't.
I'd like to be able to override a prompt.
The reason is that in general it's nice for the arch-specific Kconfig
file to include various other Kconfig files (using `source'), but
sometimes an option that usually makes sense as user-definable -- and
thus has a prompt -- _doesn't_ make sense on that particular
architecture.
Currently it seems as if the arch-specific Kconfig can do several things
in this case:
(1) Inline the more general Kconfig into the arch-specific Kconfig
(with the offending option removed, and omit the `source'). This
is undesirable for all the usual reasons (code duplication causes
bit-rot etc).
(2) Document somewhere that users shouldn't ever set option FOO, even
though it asks the question. This is confusing for users.
(3) Add a dependency on ARCH_BLAH or something to the definition of
FOO. This is probably the cleanest solution, but tends to result in
arch-specific knowledge being littered all over the place (though
this is already a general problem with the config system).
It would nice if I could just say in my arch-specific Kconfig:
option FOO
bool
set n
which would force FOO to `n' regardless of any later declarations.
-Miles
--
`Life is a boundless sea of bitterness'
next prev parent reply other threads:[~2002-11-22 2:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-21 13:33 Adrian Bunk
2002-11-21 16:55 ` Roman Zippel
2002-11-22 2:22 ` Miles Bader [this message]
2002-11-22 11:56 ` Roman Zippel
2002-11-23 12:39 ` Adrian Bunk
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=buon0o2fine.fsf@mcspd15.ucom.lsi.nec.co.jp \
--to=miles@lsi.nec.co.jp \
--cc=bunk@fs.tum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=miles@gnu.org \
--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®