Re: CONFIG_SMP patch available for 2.1.54

James Mastros (
Tue, 9 Sep 1997 23:54:43 -0400 (EDT)

On Tue, 9 Sep 1997, David Woodhouse wrote:
> This will save me an awful lot of time on the all-too-frequent occasions
> when I forget to edit the Makefile before compiling a new kernel. I've built
> SMP kernels for other peoples' machines, and I've built uniprocessor kernels
> for my own. Once I ran my machine on a single CPU for a week before I
> noticed!
Then you must not really need it; mind mailing it here? <G>

> One other thing I'd like to see is a message on booting which says
> "SMP architecture not found" if you run an SMP kernel on a single-CPU box.
> Otherwise people may never know that they're running an SMP kernel when they
> didn't mean to. I submitted a patch many moons ago, and will do so again
> after 2.1.55 is out (pre-55-1 has modifications to exactly the code I want
> to change)
Putting a "Comment me out; don't set me to 0" line right before "__SMP__ =
1" in the Makefile would also be a Good Thing (and requires 0 programing).

> If the objection to the Makefile changes is that more files will depend on
> config.h and hence get recompiled more often than they do at the moment, I
> agree with Michael that they aren't really that much of a problem; after
> all - there's lots of files which get recompiled unnecessarily anyway, so a
> few more is just pi^H^Hurinating in the wind.
Indeed. My favorite is the random-seeming modversions rebuilds...

> What I'd like to see, in fact, is a new approach to the dependencies - if a
> file includes config.h, then don't just recompile it if config.h is
> modified - only recompile it if the #defines that it uses are changed. We
> could define each CONFIG_xxx option in autoconf.h with the date and time
> that it was set, rather than just defining it to 1. So autoconf.h becomes:
> #undef CONFIG_MATH_EMULATION 19970909102900
> #define CONFIG_NET 19970909102900
> etc...

That would be wonderfull, except that you Can't Do That:
1) It would require a complete rewrite of the dependincy generation
(probably with a modified "make" command). (Admittedly, make dep seems
rather screwey to me, but that's probably just me).
2) You can't #undef somthing to a value.
3) The value of many config options is already defined (IRQs...)

> Then the dependency checking involves scanning the source file (& included
> headers) for references to CONFIG_xxxx options, and marking it in need of
> recompilation iff the change time of any of the used options is later than
> the stamp of the object file.
You could just do a sed to get a list of CONFIG_foo, but that seems like it
would get lots of mis-hits. And would be slow besides. Also, then you need
to make dep after every make *config*. And a make dep currently does a
recompile of EVERYTHING (the .depend files have a new date even if no

> My initial thought was to separate each CONFIG_ option into a separate file,
> and that source files should only include the files for the options they
> depended on:
> #include <linux/config/config_arcnet.h>
> etc...
> I don't like this because it means an explosion of small files in the
> linux/config directory, which will waste a lot of space on some filesystems,
> and generally not look nice, but it's a simple way of implementing finer
> grained dependencies without overhauling the dependency code.
> Comments, flames, abuse, money orders, etc. are as usual welcome.
Perhaps we could comprimise with having include/linux/config/config_a.h with
CONFIG_A* in it; include/linux/config/config_b.h with CONFIG_B*, etc. Note
that if anything like this is going to happen, we need mv-if-changed (really
quite trivial). Mv-if-changed is a good thing anyway.

-=- James Mastros

> --
> David Woodhouse, CB3 9AN
> Tel: 0976 658355
> Tel: 01279 402332

I can now be reached again at or
  "Shooting as [a] communications method is obsolete even here in Bosnia, so
I'll skip over it."
	-=- Dragisha Durich