On 04/12/2009 11:02 -0800, Randy Dunlap wrote: > Did you just notice that thru source code inspection or via testing of > gconfig? I noticed the problem with the following test case (with the patch NOT applied). $ rm -f .config $ make clean && make gconfig Select File->Save to save a "clean" version of .config and exit. Now let's target a specific option, e.g. CONFIG_MODULES, and check that it is present, either set to 'y' or commented out (mine is set to 'y'): $ grep 'CONFIG_MODULES' .config CONFIG_MODULES=y $ make gconfig At this point I see that module support has the NEW flag, but it shouldn't! Exit, then manually remove CONFIG_MODULES from the .config file: $ sed -i '/CONFIG_MODULES/d' .config $ make clean && make gconfig Now I see that module support is not flagged as NEW, but it should. I concluded that the logic was inverted. I looked up the string NEW in the source and found the piece of code cited below. Then I tried and figured out what that code was supposed to do, and thought that it made more sense that the NEW flag was added when an option (sym) had not been assigned a value yet (!sym_has_value). So I worked out this simple patch. I've been using it for some time, and it works for me, I mean, if I try the above test case, it gives the expected results. > Well, for me, with just some random config file that has > CONFIG_MODULES=y > CONFIG_BLOCK=y > > gconfig with this patch says: > > Enable loadable module support > Enable the block layer (NEW) > > and gconfig without this patch says: > > Enable loadable module support (NEW) > Enable the block layer > > > I'm confuzed. Go figure. Yes, it makes no sense. Unfortunately I have no experience with .config files generated in any other way than written by the GTK configurator... Please bear in mind that I'm not a kernel developer, I just recompile my kernel when a new version is released. I usually copy my .config file from the previous kernel directory and then use the "NEW" flag to tell which options were added since my last compile and thus deserve my attention. --- Matteo -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
