Re: CONFIG_SMP

Michael Elizabeth Chastain (mec@shout.net)
Thu, 15 Oct 1998 15:38:56 -0500


Hi David,

At this point, I think it's too late for 2.2. CONFIG_SMP is very well
tested on the i386 architecture. The other major SMP architectures are
sparc and sparc64. CONFIG_SMP is not tested on these architectures
because the base 2.1.XX does not build on these architectures.

When 2.3 work begins, I am planning to re-work the patch into two
separate patches. The first patch will have the minimal Makefile
changes. It will also export the legacy __SMP__ symbol to make
life easier for the other arch source trees. As soon as the first
patch goes in, users will see CONFIG_SMP in the configuration menu
and it will work correctly and they will be happy.

The second patch, or group of patches, will systematically change __SMP__
to CONFIG_SMP in all the *.h and *.c files. That way I can work through
the arch maintainers and the patches can flow more gracefully.

This is all 2.3 work, it's too late for 2.2, unless Linus speaks up
and says he wants to make a special exception.

Linus had a reason for making it like this. The reason is: if CONFIG_SMP
is an option, almost every file will #include <linux/config.h>,
so changing any configuration option would force a kernel rebuild.
That reason is obsolete now for two reasons: (1) about 90% of the source
files depend on config.h already anyways; and (2) the 2.1.XX Smart Config
feature removes that rebuilding work.

Last year I saw a ZD-NET review that said configuring an SMP system is
a long difficult poorly documented process, which it is, especially for
people who are coming from other operating systems and aren't already
familiar with the process. I agree with this review and in 2.3 I want
to move all the Makefile-resident options should into the normal
configuration process.

Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"

-
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/