[lkml]   [2001]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Cross-referencing frenzy
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
> 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] Makefile

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?" -- Dogbert
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:26    [W:0.170 / U:5.256 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site