once upon a time, as i was diving into the kernel Kbuild infrastructure, i wrote a number of scripts that would sanity check the contents of Kconfig files against source files and Makefiles -- not sure if there's a better way to do that these days, but i posted some of them here if people want to run any of them against their favourite kernel subsystem: http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts by "sanity check", i mean that there are a few basic properties of the kernel build files that should be true, such as: 1) if a Kconfig file defines a config variable, someone else somewhere should be checking it 2) if a source file tests an alleged Kconfig variable, some Kconfig file should define it 3) if a Makefile conditionally compiles based on a Kconfig variable, some Kconfig file should define it and so on, and so on -- pretty straightforward stuff. and it was surprising how many irregularities there were (admittedly many of them minor and causing no problem). for example, my script "find_badref_make_configs.sh" would search either the entire kernel tree or just the directory given by the optional argument, and identify all Makefiles that tested for "CONFIG__*" variables that were nowhere defined in the tree. here's the output from this morning just checking the drivers/ directory: http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup_scripts#find_badref_make_configs.sh_.28updated_Sep_17.2C_2014.29 there are two typical causes of such things: * an incomplete *removal* of some feature, or * an imcomplete *addition* of some feature for the "ARCH_HIP04" variable listed there, it didn't take long to stumble on this web page where someone points out that very thing: http://www.gossamer-threads.com/lists/linux/kernel/2006426 in short, someone added the source and Makefile for that feature, but hadn't yet added the Kconfig content -- generally frowned upon. doing all this once upon a time had a number of benefits for me: 1) forced me to really understand the Kbuild infrastructure 2) improved my shell programming skills 3) let me get some patches into the kernel 4) occasionally, found an actual bug that deserved fixing, for which maintainers were grateful i have no idea if there's something better these days to do the same thing -- is there? otherwise, others are free to play with those scripts and improve them, i'm sure they're not perfect, they used to generate quite a number of false positives until i reworked them slightly. thoughts? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
