From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Jes Sorensen <jes@trained-monkey.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] bring sanity to div64.h and do_div usage
Date: Fri, 22 Feb 2002 11:05:58 -0500 [thread overview]
Message-ID: <3C766C66.8EF68046@mandrakesoft.com> (raw)
In-Reply-To: <5.1.0.14.2.20020208113710.04ecedf0@pop.cus.cam.ac.uk> <20020207234555.N17426@altus.drgw.net> <5.1.0.14.2.20020208181656.03862ec0@pop.cus.cam.ac.uk> <d37kp5v9y5.fsf@lxplus050.cern.ch> <3C7660F5.FC238A7E@mandrakesoft.com> <15478.25001.512565.628500@trained-monkey.org> <3C76631C.E685815D@mandrakesoft.com> <15478.25845.343591.883309@trained-monkey.org>
Jes Sorensen wrote:
>
> >>>>> "Jeff" == Jeff Garzik <jgarzik@mandrakesoft.com> writes:
>
> Jeff> Jes Sorensen wrote:
> >> Why? CONFIG_$ARCH only makes sense if you can enable two
> >> architectures in the same build. What does CONFIG_M68K give you that
> >> __mc68000__ doesn't provide?
>
> Jeff> 1) it is a Linux kernel standard. all arches save two define
> Jeff> CONFIG_$arch.
>
> Ehm, what standard? the standard way has always been ARCH==, CONFIG_PPC
> used to be the only place using this and all it did was to make things
> uglier and inconsistent.
*shrug* I've known about this for years. And every arch but m68k and
cris follows the standard.
> Jeff> 2) you have two tests, "ARCH==m68k" in config.in and "__mc68000__"
> Jeff> in C code. CONFIG_M68K means you only test one symbol, the same
> Jeff> symbol, in all code.
>
> If you want to do that, then one should use CONFIG_<ARCH> in the
> Makefiles as well.
I'm betting a few special makefiles require $ARCH information when
.config is info is not available. Otherwise, agreed.
> Jeff> 3) as this thread shows, due to #1, users -expect- that
> Jeff> CONFIG_M68K will exist
>
> Ehm, most kernel developers will expect ARCH== in Config.in as thats
> how it's always been.
and I forgot about this flat-out bug:
4) you cannot test ARCH==m68k as a component of dep_xxx declarations.
And yes, this is a requirement, this is used currently in */config.in
all over the kernel tree.
Jeff
--
Jeff Garzik | "UNIX enhancements aren't."
Building 1024 | -- says /usr/games/fortune
MandrakeSoft |
next prev parent reply other threads:[~2002-02-22 16:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-08 5:45 [PATCH] bring sanity to div64.h and do_div usage Troy Benjegerdes
2002-02-08 12:15 ` Anton Altaparmakov
2002-02-08 17:57 ` Troy Benjegerdes
2002-02-08 18:49 ` Maciej W. Rozycki
2002-02-08 19:34 ` Anton Altaparmakov
2002-02-08 21:16 ` Troy Benjegerdes
2002-02-15 18:47 ` Updated div64.h cleanup Troy Benjegerdes
2002-02-22 14:59 ` [PATCH] bring sanity to div64.h and do_div usage Jes Sorensen
2002-02-22 15:17 ` Jeff Garzik
2002-02-22 15:20 ` Jes Sorensen
2002-02-22 15:26 ` Jeff Garzik
2002-02-22 15:34 ` Jes Sorensen
2002-02-22 16:05 ` Jeff Garzik [this message]
2002-02-22 15:55 ` Andreas Schwab
2002-02-22 16:00 ` Jeff Garzik
2002-02-22 16:08 ` Nicolas Pitre
2002-02-08 12:29 ` Anton Altaparmakov
2002-02-08 19:04 ` 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=3C766C66.8EF68046@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=jes@trained-monkey.org \
--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