[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zuly-WPqwxqWXylP@gallifrey>
Date: Tue, 17 Sep 2024 12:15:53 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, kees@...nel.org
Subject: Re: Dead code by symbols
* David Hildenbrand (david@...hat.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 |_______/
Powered by blists - more mailing lists