since i, on an occasional basis, run a set of scanning scripts i
wrote and promptly annoy the crap out of everyone with the results,
i'm open to the proper way to do this scanning and get the results out
there to people who might be interested while not bugging those folks
who aren't.
a while back, a few people suggested a wiki page, while others
disagreed, suggesting that no one will follow a link to a wiki page
and will only read what's directly on the list. grapple, grapple.
in the end (as i'm sure you're aware by now), i post the results
here:
http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup
i'm convinced that there's value in the links i've promoted lately --
scanning Kconfig files for unused or "bad" CONFIG variables, not just
to clean historical cruft out of those files but because, on occasion,
the scanning really does track down typoes and errors.
not quite so critical is a "style" script i wrote, which looks for
places to simplify code by using some of the macros/functions defined
in include/linux/kernel.h. i ran that script again earlier today, and
posted only *some* of the results here:
http://www.crashcourse.ca/wiki/index.php/The_style_script
long story short, i have a *pile* of scripts and sub-scripts i'm happy
to run and post the results of since it takes practically zero time on
my part, i'm just open to what folks think is the most productive way
to do that, and also for any other scanning i can add since, by now,
any other patterns to scan for would just represent adding a line or
two to a script.
thoughts?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================
Robert P. J. Day wrote:
> since i, on an occasional basis, run a set of scanning scripts i
> wrote and promptly annoy the crap out of everyone with the results,
> i'm open to the proper way to do this scanning and get the results out
> there to people who might be interested while not bugging those folks
> who aren't.
>
I love the idea!
What about an announcement-only mailing list that interested parties
could subscribe to?
b.g.
--
Bill Gatliff
[email protected]
[added Jiri on CC]
On Mon, Apr 27, 2009 at 04:46:46PM -0400, Robert P. J. Day wrote:
>
> since i, on an occasional basis, run a set of scanning scripts i
> wrote and promptly annoy the crap out of everyone with the results,
> i'm open to the proper way to do this scanning and get the results out
> there to people who might be interested while not bugging those folks
> who aren't.
>
> a while back, a few people suggested a wiki page, while others
> disagreed, suggesting that no one will follow a link to a wiki page
> and will only read what's directly on the list. grapple, grapple.
>
> in the end (as i'm sure you're aware by now), i post the results
> here:
>
> http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup
>
> i'm convinced that there's value in the links i've promoted lately --
> scanning Kconfig files for unused or "bad" CONFIG variables, not just
> to clean historical cruft out of those files but because, on occasion,
> the scanning really does track down typoes and errors.
>
> not quite so critical is a "style" script i wrote, which looks for
> places to simplify code by using some of the macros/functions defined
> in include/linux/kernel.h. i ran that script again earlier today, and
> posted only *some* of the results here:
>
> http://www.crashcourse.ca/wiki/index.php/The_style_script
>
> long story short, i have a *pile* of scripts and sub-scripts i'm happy
> to run and post the results of since it takes practically zero time on
> my part, i'm just open to what folks think is the most productive way
> to do that, and also for any other scanning i can add since, by now,
> any other patterns to scan for would just represent adding a line or
> two to a script.
>
> thoughts?
Yes. I wonder why you take the time to generate the output and email
it but then stop there instead of just sending patches?
grep -A5 TRIVIAL MAINTAINERS
Perhaps Jiri can pick up some of the patches that remove stale config
symbols, correct typos etc.
Yes, these corrections take care of cruft. But I think installing
output of scripts on wiki pages and asking for other people to fix
them up is more than these things deserve. It's a bit like writing a
list containing
- wash up mug
- grind beans
- boil water
- put grinded beans in mug
- put filter in mug
- put hot water in mug
instead of just making coffee already.
Hannes
On Tue, 28 Apr 2009, Johannes Weiner wrote:
> > long story short, i have a *pile* of scripts and sub-scripts i'm happy
> > to run and post the results of since it takes practically zero time on
> > my part, i'm just open to what folks think is the most productive way
> > to do that, and also for any other scanning i can add since, by now,
> > any other patterns to scan for would just represent adding a line or
> > two to a script.
> > thoughts?
> Yes. I wonder why you take the time to generate the output and email
> it but then stop there instead of just sending patches?
>
> grep -A5 TRIVIAL MAINTAINERS
>
> Perhaps Jiri can pick up some of the patches that remove stale config
> symbols, correct typos etc.
Absolutely. I'll happily apply anything trivial enough (typo fixes,
removal of obviously unused symbols/config options, etc).
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 28 Apr 2009, Jiri Kosina wrote:
> On Tue, 28 Apr 2009, Johannes Weiner wrote:
>
> > > long story short, i have a *pile* of scripts and sub-scripts i'm
> > > happy to run and post the results of since it takes practically
> > > zero time on my part, i'm just open to what folks think is the
> > > most productive way to do that, and also for any other scanning
> > > i can add since, by now, any other patterns to scan for would
> > > just represent adding a line or two to a script.
> > > thoughts?
> > Yes. I wonder why you take the time to generate the output and
> > email it but then stop there instead of just sending patches?
> >
> > grep -A5 TRIVIAL MAINTAINERS
> >
> > Perhaps Jiri can pick up some of the patches that remove stale
> > config symbols, correct typos etc.
>
> Absolutely. I'll happily apply anything trivial enough (typo fixes,
> removal of obviously unused symbols/config options, etc).
the *problem* is that, sometimes, it's not obvious. as in, when a
Kconfig file has a pile of unused config options but it turns out that
those were added for future consideration to match up with code that
hasn't been added yet and the subsystem maintainer knows about it but
wants it to stay (IMHO, a really bad idea -- adding kernel features in
incomplete pieces, but whatever).
in any event, my only point is that, sometimes, only the subsystem
maintainer really knows how to resolve something that *looks*
trivially resolvable or removable. IIRC, a simple observation on the
unused symbols HAVE_READQ and HAVE_WRITEQ sparked a lengthy discussion
that would never have happened if the "obvious" deletion on those
symbols had been done.
the right thing to do is not always obvious.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================
On Tue, 28 Apr 2009, Robert P. J. Day wrote:
> > > Perhaps Jiri can pick up some of the patches that remove stale
> > > config symbols, correct typos etc.
> > Absolutely. I'll happily apply anything trivial enough (typo fixes,
> > removal of obviously unused symbols/config options, etc).
> the *problem* is that, sometimes, it's not obvious. as in, when a
> Kconfig file has a pile of unused config options but it turns out that
> those were added for future consideration to match up with code that
> hasn't been added yet and the subsystem maintainer knows about it but
> wants it to stay (IMHO, a really bad idea -- adding kernel features in
> incomplete pieces, but whatever).
Hmm ... do you have any particular outstanding examples of this?
--
Jiri Kosina
SUSE Labs
On Wed, 29 Apr 2009, Jiri Kosina wrote:
> On Tue, 28 Apr 2009, Robert P. J. Day wrote:
>
> > > > Perhaps Jiri can pick up some of the patches that remove stale
> > > > config symbols, correct typos etc.
> > > Absolutely. I'll happily apply anything trivial enough (typo fixes,
> > > removal of obviously unused symbols/config options, etc).
> > the *problem* is that, sometimes, it's not obvious. as in, when a
> > Kconfig file has a pile of unused config options but it turns out
> > that those were added for future consideration to match up with
> > code that hasn't been added yet and the subsystem maintainer knows
> > about it but wants it to stay (IMHO, a really bad idea -- adding
> > kernel features in incomplete pieces, but whatever).
>
> Hmm ... do you have any particular outstanding examples of this?
historically, plenty, based on the number of times i've submitted
patches to various maintainers to remove unused symbols, only to be
told that those symbols were added in a preliminary fashion, and the
accompanying code should be along any day now. obviously, that
doesn't cause any actual problems but it certainly messes up the
history of a feature by breaking its introduction over more than one
patch.
and as for *current* examples, well, there's this page:
http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables
one recent example was MAC80211_VERBOSE_SPECT_MGMT_DEBUG, if you
wanted an actual reference.
really, i'm *aware* that 99% of this scanning and cleanup is benign.
but that final 1% sometimes really does represent a bug and, since i
have the scripts and it's pretty much free to run them whenever i
want, we're back to the original question -- what's the best venue to
distribute this info so as not to bore to tears the people who don't
care about it?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================