Re: Dead code by symbols

["Dr. David Alan Gilbert" <linux@treblig.org>]

* David Hildenbrand (david@redhat.com) wrote:
> On 16.09.24 14:33, Dr. David Alan Gilbert wrote:
> > Hi David,
> >    A while ago we were chatting about me spotting dead structs, and
> > you wondered if it might be possible to spot dead functions that
> > were exported from an object but never used - and I've been trying
> > it for the last few days.
> > 
> >    I'm pretty early on, but it's already got some fun things:
> 
> Cool, stuff! :)
> 
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=6a36d828bdef0e02b1e6c12e2160f5b83be6aab5
> >    Core code not used for ~20 years
> > 
> > https://lore.kernel.org/lkml/1690847.1726346402@warthog.procyon.org.uk/
> >    A bug! A recently added function that lost the place it was wired up
> >    so was currently unused.
> 
> That is really nice!
> 
> > 
> > https://lore.kernel.org/lkml/ZuXOWjvVYa64c1-5@gallifrey/
> >    A few small dead files.
> > 
> > Now, it does take some more guesswork, for example an unused function
> > which was added a couple of years back, might be something that's
> > there for consistency,
> 
> I know people will find reasons to do something like that, but we really
> *shouldn't* be maintaining / dragging along dead code that nobody might ever
> use.

One example is lib/base64.c base64_encode - that's not used, but the base64_decode
in the same file is used by nvme; I've not convinced myself if it makes sense
to take the encode out or not.
(We do have ceph_base64_encode with slightly different base64 behaviour,
and then there's chap_base64_decode and ceph_base64_decode which are all different;
it's pretty hideous)

> > might have been forgotten to be wired up,
> 
> Forgotten as in "BUG" or as in "ran out of steam" ?

BUG like the afs one above where the function exists but the line
to use it got lost.
But there are 'ran out of steam' ones as well - eg bc9ab6d31c4f
added a function for 'runtime reconfiguration' to an audio codec
with a note that some systems require it; as far as I can tell
it was never used.  Since that was over 10 years ago it's probably
time for it to go, but if it was only a year or so old then maybe
it would still be something that might be getting added.

> > or might just be something that's going to be used but the
> > authors haven't got to it yet, e.g.
> >     https://lore.kernel.org/lkml/ZuRGRKU9bjgC52mD@gallifrey/
> 
> Yes, that' a valid case.
> 
> > 
> > My patience varies from Ooh core code, to meh old driver to very meh
> > for old undead staging code.
> 
> :)
> 
> > 
> >    I've got some nasty awk which kind of works some of the time;
> > but it does require a lot of handholding; often things like inlining
> > isn't spotted so gives a false positive, and I'm only looking at
> > the objects from a single architecture, so again have to grep
> > for the symbol name to make sure it's not used by a different
> > architecture build.
> > 
> >    And heck, I wish git log -G was faster.
> 
> :)
> 
> > 
> > Anyway, thanks for the suggestion!
> 
> Glad you're able to spot some nice (+fun, otherwise you wouldn't be doing it
> ;) ) things!

Dave

> -- 
> Cheers,
> 
> David / dhildenb
> 
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/