[lkml]   [1997]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CONFIG_SMP patch available for 2.1.54

    Maby it would be better to say:

    "SMP Kernel Running in Uniprocssor mode"
    "Uniprocessor Kernel"

    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!
    > 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)
    > 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.
    > 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...
    > 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.
    > This will make the dependency checking more complex, hence slower, but will
    > mean that we no longer need to recompile the whole kernel when only one option
    > is changed.
    > I'm not even sure if what I'm suggesting is possible, but if so, and if people
    > like the idea, I'm happy to look into implementing it (although possibly next
    > month after I finish here and go back to College, where I'm not paid, so can
    > work on what I like).
    > 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>
    > #ifdef CONFIG_ARCNET
    > 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.
    > --
    > David Woodhouse, CB3 9AN
    > Tel: 0976 658355
    > Tel: 01279 402332

     \ /
      Last update: 2005-03-22 13:40    [W:0.022 / U:8.844 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site