public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Keith Owens <kaos@ocs.com.au>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"Adam J. Richter" <adam@yggdrasil.com>,
	linux-kernel@vger.kernel.org
Subject: Re: linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
Date: Sat, 30 Jun 2001 13:10:50 +0100	[thread overview]
Message-ID: <20010630131050.D12788@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20010630102024.A12009@flint.arm.linux.org.uk> <3465.993901530@ocs3.ocs-net>
In-Reply-To: <3465.993901530@ocs3.ocs-net>; from kaos@ocs.com.au on Sat, Jun 30, 2001 at 09:45:30PM +1000

On Sat, Jun 30, 2001 at 09:45:30PM +1000, Keith Owens wrote:
> CONFIG_bar can be undefined, not 'n'.  While that can cause problems,
> it is also valid config code.  If I interpret AC's cryptic comments
> correctly, there may be code which assumes that undefined variables are
> just that, undefined.  Setting all variables to 'n' initially by Adam's
> script will break such code.

Agreed.   The person who should know for sure how the configuration system
works is ESR.

> I still think this is the best approach, against 2.4.5-ac22.

One small concern - does it work properly with xconfig and menuconfig?
I seem to remember that they re-evaluate choices, and I have this feeling
that I've seen unselectable symbols caused by define_bool SYM n type stuff.

Note also that we in the ARM port currently have 43 such symbols in either
Linus' or my tree, and there are getting on for 90 such symbols in existence
throughout the ARM trees.  (There are around 90 registered ARM machine types
at the moment, each one has their own CONFIG symbol).

Your config.in file could get very large. ;)

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  reply	other threads:[~2001-06-30 12:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-30  4:35 linux-2.4.6-pre6: numerous dep_{bool,tristate} $CONFIG_ARCH_xxx bugs Adam J. Richter
2001-06-30  7:26 ` Alan Cox
2001-06-30  9:20   ` Russell King
2001-06-30 11:43     ` Alan Cox
2001-06-30 11:58       ` Russell King
2001-06-30 12:01         ` Alan Cox
2001-06-30 12:02           ` Russell King
2001-06-30 11:45     ` Keith Owens
2001-06-30 12:10       ` Russell King [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-06-30 14:57 Adam J. Richter
2001-06-30 15:01 ` Russell King
2001-07-01  2:39   ` Keith Owens
2001-06-30 13:32 Adam J. Richter
2001-06-30  9:38 Adam J. Richter
2001-06-30  4:40 Adam J. Richter
2001-06-30  7:23 ` Alan Cox
2001-06-29 14:10 Adam J. Richter
2001-06-29 14:21 ` Keith Owens
2001-06-29 14:30   ` Russell King
2001-06-29 14:41     ` Keith Owens
2001-06-29 15:19     ` Alan Cox
2001-06-29 14:30 ` Jeff Garzik

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=20010630131050.D12788@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=adam@yggdrasil.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=kaos@ocs.com.au \
    --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