Re: Cross-referencing frenzy

[Andreas Dilger]

Eric writes:
> So.  I've written a cross-reference analyzer for the configuration symbol
> namespace.  It's included with CML 1.2.0, which I just released.  The
> main reason I wrote it was to detect broken symbols.
> 
> A symbol is non-broken when:
> 	* It is used in either code or a Makefile
> 	* It is set in a (CML1) configuration file
> 	* It is either derived from other non-broken symbols 
>           or described in Configure.help
> If it fails any one of these conditions, it's cruft that makes the kernel
> code harder to maintain and understand.  The least bad way to be broken is
> to be useful but not documented.  The most bad way is to lurk in code, doing
> nothing but making the code harder to understand and maintain.

Could you make a list that splits the symbols up by each of the above
failure conditions?  It would make the task of deciding how to fix the
"problem" more apparent.

Also, it appears that some of the symbols you are matching are only in
documentation (which isn't necessarily a bad thing).  I would start with:

*.[chS] Config.in Makefile Configure.help

However, I'm not sure that your reasoning for removing these is correct.
For example, one symbol that I saw was CONFIG_EXT2_CHECK, which is code
that used to be enabled in the kernel, but is currently #ifdef'd out with
the above symbol.  When Ted changed this, he wasn't sure whether we would
need the code again in the future.  I enable it sometimes when I'm doing
ext2 development, but it may not be worthy of a separate config option
that 99.9% of people will just be confused about.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert