From: Hugh Dickins <hugh@veritas.com>
To: Keith Owens <kaos@ocs.com.au>
Cc: linux-kernel@vger.kernel.org, elenstev@mesatop.com,
kbuild-devel@lists.sourceforge.net
Subject: Re: Rename all derived CONFIG variables
Date: Mon, 12 Mar 2001 12:12:25 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.21.0103121149540.1194-100000@localhost.localdomain> (raw)
In-Reply-To: <20736.984380602@ocs3.ocs-net>
On Mon, 12 Mar 2001, Keith Owens wrote:
> In 2.4.2-ac18 there are 130 CONFIG options that are always derived from
> other options, the user has no control over them. It is useful for the
> kernel build process to know which variables are derived and which
> variables the user can control.
If it's useful for the (future?) kernel build process to know this,
shouldn't that config/build process derive this info itself, rather
than going by _DERIVED on the end of a CONFIG_ name?
And aren't there many CONFIG_ options (I think your "always" implies
so) which are derived in some cases (e.g. on some architectures),
specified by the user in others? Those don't get to be called
_DERIVED though often they are derived.
And easy to imagine an option always derived in one release, sometimes
specified in the next, always derived in the next... Yes, we can
keep on editing the CONFIG_ name in all sources affected, but I
just don't think the name should be trying to carry that info.
Hugh
prev parent reply other threads:[~2001-03-12 12:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-12 7:03 Rename all derived CONFIG variables Keith Owens
2001-03-12 7:25 ` Jeff Garzik
2001-03-12 14:24 ` Alan Cox
2001-03-12 8:26 ` Peter Samuelson
2001-03-12 8:53 ` [kbuild-devel] " Eric S. Raymond
2001-03-12 9:18 ` Keith Owens
2001-03-12 14:28 ` Alan Cox
2001-03-14 21:34 ` Oliver Xymoron
2001-03-12 11:37 ` Philipp Rumpf
2001-03-12 12:12 ` Hugh Dickins [this message]
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=Pine.LNX.4.21.0103121149540.1194-100000@localhost.localdomain \
--to=hugh@veritas.com \
--cc=elenstev@mesatop.com \
--cc=kaos@ocs.com.au \
--cc=kbuild-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).