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
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.
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
kbuild-devel mailing list