From: David Hildenbrand <david@redhat.com>
To: "Dr. David Alan Gilbert" <linux@treblig.org>
Cc: linux-kernel@vger.kernel.org, kees@kernel.org
Subject: Re: Dead code by symbols
Date: Tue, 17 Sep 2024 13:39:35 +0200 [thread overview]
Message-ID: <d289061d-7dc8-41d7-a166-4b3b8dce886d@redhat.com> (raw)
In-Reply-To: <ZugliLgw5VFb9yau@gallifrey>
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.
> might have been forgotten to be wired up,
Forgotten as in "BUG" or as in "ran out of steam" ?
> 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!
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-09-17 11:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-16 12:33 Dead code by symbols Dr. David Alan Gilbert
2024-09-17 11:39 ` David Hildenbrand [this message]
2024-09-17 12:15 ` Dr. David Alan Gilbert
2024-09-18 6:16 ` Christoph Hellwig
2024-09-18 10:55 ` Dr. David Alan Gilbert
2024-09-19 8:13 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d289061d-7dc8-41d7-a166-4b3b8dce886d@redhat.com \
--to=david@redhat.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@treblig.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.