lkml.org 
[lkml]   [2000]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Replacing __SMP__ by CONFIG_SMP globally in linux-2.3.39.


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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.170 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site