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: "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: Fri, 29 Jun 2001 15:30:36 +0100	[thread overview]
Message-ID: <20010629153036.A10196@flint.arm.linux.org.uk> (raw)
In-Reply-To: <200106291410.HAA10170@baldur.yggdrasil.com> <27582.993824469@ocs3.ocs-net>
In-Reply-To: <27582.993824469@ocs3.ocs-net>; from kaos@ocs.com.au on Sat, Jun 30, 2001 at 12:21:09AM +1000

On Sat, Jun 30, 2001 at 12:21:09AM +1000, Keith Owens wrote:
> Create arch/Config.in which contains
> 
>   define_bool CONFIG_ARCH_i386 n
>   define_bool CONFIG_ARCH_ia64 n
>   define_bool CONFIG_ARCH_sparc n
> 
> etc., then change each of the arch/xxx/Config.in files to
> source arch/Config.in as their first line first.  Still ugly but the
> mainline configs will be much more readable.  It also guarantees that
> any future tests on $CONFIG_ARCH_somearch will work, even if the code
> does not use if statements.

I'd rather that we fixed dep_* so that undefined symbols were treated as
'n', just like the makefiles treat undefined symbols.

On ARM, we have a lot of CONFIG_ARCH_* variables (which yes, I know, should
be CONFIG_MACH_*, but its too late to change it now), and cluttering up the
place with lots of if ... then fi stuff is much less readable than the
dep_* stuff.

--
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-29 14:31 UTC|newest]

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

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=20010629153036.A10196@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=adam@yggdrasil.com \
    --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