On Sun, 16 Sep 2007, Oleg Verych wrote: > On Sun, Sep 16, 2007 at 08:58:03AM -0400, Robert P. J. Day wrote: > > On Sun, 16 Sep 2007, Sam Ravnborg wrote: > > > > > A summary of what is planned to be submitted in next merge > > > window for kbuild. The shortlog below have additional details > > > but the headlines are: > > ... > > > o add script to find unused kconfig symbols (try it!) > > > > based on my experiences with this, unless you filter carefully, > > you're going to end up with a *whack* of false positives given the > > number of developers who elect to name their local macros starting > > with a prefix of "CONFIG_". good luck dealing with *that*. :-) > > I saw you patches about that kconfig symbols usage, your > developments of *the* script. I also happened to see > `linux-2.4.X/checkconfig.pl`. Now somebody else proposed something > related to kbuild tree. So, what was your point in doing that, why > your work didn't ended up in `linux/scripts/'?
i've never looked at checkconfig.pl, i didn't even know it existed. i just wrote a simple shell script that scanned for the obvious occurrence of "CONFIG_FUBAR" symbols for which there is no corresponding "FUBAR" definition in a Kconfig* file somewhere. i think i can guarantee that i won't *miss* any but, as i've mentioned before, i definitely display a lot of false positives based on developers' less-than-ideal choice of macro names, and i just haven't put any effort into filtering those out since it doesn't seem worth the time. as for adding a check like that to the Kbuild structure itself, i get the feeling that you'd run into the same philosophy as adding a debugger to the kernel would get you. i don't think it's worth over-complicating the Kbuild structure -- i think it's just easier to leave stuff like that as external, cheap, one-off utility scripts. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
