Re: Cross-referencing frenzy

Richard Gooch (rgooch@atnf.csiro.au)
Thu, 19 Apr 2001 15:06:44 +1000


Edward S. Marshall writes:
> On Thu, Apr 19, 2001 at 01:11:07AM -0300, Rik van Riel wrote:
> > On Thu, 19 Apr 2001, Richard Gooch wrote:
> > > esr wrote:
> > > > CONFIG_DEVFS: Documentation/filesystems/devfs/ChangeLog
> > >
> > > These are options that used to be used,
> > ....
> > > These should not be removed
> >
> > This makes no sense at all. Do you have any particular
> > reason for keeping this deadwood around ?
>
> Look at the filename. ;-) They're not being kept around, they just
> happen to be mentioned in the devfs ChangeLog, and esr's overzealous
> crossref tool caught them. *grin*

Exactly. A ChangeLog should pre preserved for all time. It is an
incredibly useful tool. Many times I've gone back and checked when
something was done, and in relation to other changes before, after or
around the same time.

> Perhaps the tool should be modified to exempt comments in code and
> files in Documentation/*? :-)

Except the CONFIG_APM_IGNORE_SUSPEND_BOUNCE was in the apm.c source
file (in a ChangeLog). So just ignoring Documentation/ won't solve the
problem.

One trick I've used on my own (non-Linux) code is to insert a space
after the first underscore. That fools the global search, but leaves
the essence of the ChangeLog entry. It's a bit hackish, though.

A cleaner solution is to parse the source code, ignoring comment
blocks. However, that's a bit more work.

Either way, the solution adopted has to kill off the false
positives. It's not good enough to build up a list of CONFIG options
to ignore, as it will get stale. Furthermore, that list might be
overlooked by someone on a cleanup crusade, with the result that a
patch gets sent to Linus which "fixes" the "broken" CONFIG symbols.
And since too many global patches are not Cc'ed to the maintainers,
this kind of crap slips by.

Frankly, I'd rather see stale symbols left around, and have it really
difficult to detect them. Eric is making a tool that makes it too easy
for a random person to "detect" "problems" and then "fix" them,
thinking that "progess" is being made. In reality, it's just regress.

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/