Linux-kernel mailing list archive 2000-02,: Re: [PATCH] Replacing __SMP__ by CONFIG_SMP globally in linux-2.3.39.

# Re: [PATCH] Replacing __SMP__ by CONFIG_SMP globally in linux-2.3.39.

Chris Noe (stiker@northlink.com)
Wed, 12 Jan 2000 20:07:40 -0500 (EST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alexander Viro: "Re: February 30th 2000"
- Previous message: Elmer Joandi: "Re: [RFC] Maintaining persistent kernel data across module unload/reload"

On Wed, 12 Jan 2000, Richard B. Johnson wrote:

> On Wed, 12 Jan 2000, Niels Kristian Bech Jensen wrote:
>
> > A patch that replaces __SMP__ by CONFIG_SMP throughout the linux-2.3.39
> > kernel source tree can be found at
> >
> > http://www.image.dk/~nkbj/patches/config-smp-2.3.39.bz2
> >
> > The patch can be applied to pre-patch-2.3.40-1 as well. Beware that
> > __SMP__ is no longer defined when the patch has been applied.
> >
> > --
>
> What is its purpose? __SMP__ is not just defined or not defined from
> the linux kernel source directory, but also used for writing modules
> which, in fact, may not exist within the kernel source directory at
> all.
>
> So, if such a patch goes into the kernel, module makefiles now have
> to be modified to define "CONFIG_SMP" instead of "__SMP__" which,
> since they may not even have a "configuration", becomes just another
> PITA to support "change for the sake of change".

As I just wrote to nkbj, it should be cake to do something like:

#ifdef (__SMP__)
#define CONFIG_SMP
#warning -D__SMP__ will work in 2.4, but not 2.5/2.6
#warning Please update your makefile to use -DCONFIG_SMP instead.
#endif

in say modules.h (or whichever module include file is required to build a
full-fledged module). Then we kill that little 5 line check once everyone
is into 2.5 mode.

The reasoning isn't just to change semantics for no good reason. It's
because we have a semi-decent "configuration system" with all its
dependency logic and wonderful stuff, yet we still resort to simply
passing a define on the command line of gcc. Why? All that does is cause
confusion: first, because there is absolutely *no need* (IMHO) to use a
separate "mechanism" to decide whether or not to compile something SMP,
when we have a perfectly good method using the autogenerated CONFIG_SMP in
autoconf.h

Why should someone need to tell the kernel twice that it needs SMP (First
by saying yes to CONFIG_SMP, then having that yes or no answer apply a
-D__SMP__ to the cmdline) when we could just use CONFIG_SMP all around and
gain that much more consistency.

My thinking is that if you can pass for instance -DCONFIG_XXX on a command
line to gcc, its much better to have that work for *every option*
including SMP. Especially when its such an easy fix. You shouldn't have to
remember that you can do -DCONFIG_XXX -DCONFIG_YYY but have to do
-D__SMP__ for SMP. That's crap. :)

Chris Noe
(stiker@northlink.com)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Alexander Viro: "Re: February 30th 2000"
- Previous message: Elmer Joandi: "Re: [RFC] Maintaining persistent kernel data across module unload/reload"