Messages in this thread | | | Date | Wed, 12 Jan 2000 20:07:40 -0500 (EST) | From | Chris Noe <> | Subject | Re: [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/
| |