From: Julia Lawall <julia.lawall@inria.fr>
To: Joe Perches <joe@perches.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Dan Carpenter <error27@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Greg KH <gregkh@linuxfoundation.org>
Subject: Re: linux-kernel: Unused static inline functions
Date: Fri, 24 Apr 2020 18:07:30 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.2004241806220.2344@hadrien> (raw)
In-Reply-To: <572b03bdc3eed286c5ed20887d42f674bd93336e.camel@perches.com>
On Thu, 23 Apr 2020, Joe Perches wrote:
> (adding Julia Lawall and Dan Carpenter who may have ideas too)
>
> On Thu, 2020-04-23 at 11:57 -0700, Nick Desaulniers wrote:
> > I've been mulling over teaching a class internally at Google on
> > getting started contributing to the Linux kernel. I think this idea
> > (removing dead static inline functions) is perfect for having lots of
> > small little tasks that are clear wins. Do you have any other ideas
> > for work that there's a lot of? Like lots of small little bite sized
> > tasks? Maybe more fallthrough conversion? Anything else?
>
> Some generic ideas:
>
> o look for always unused/unreferenced, or always static
> value function arguments and remove them
>
> o int function returns constrained to 0 or 1 could be
> converted to bool.
>
> And some logging ideas:
>
> o printk to tracing conversions
>
> o removal of printks used just for function tracing
> as ftrace works well
>
> o pr_<level> macro conversions to functions to save
> object space
>
> o singletons for pr_fmt
>
> o default use of #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> and removal of the ~1200 current defines treewide
>
> > Happy to have folks use your script and add your suggested by tag.
>
> Suggested-by doesn't have much value to me,
> especially for scripted stuff.
>
> I'd be happy enough that it gets done eventually.
Perhaps typedefs for structures? Using standard list operations? In
staging there are a lot of camel case and variables whose names
incorporate their type.
julia
next prev parent reply other threads:[~2020-04-24 16:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-06 15:41 [PATCH] sched/cputime: silence a -Wunused-function warning Qian Cai
2020-03-06 17:13 ` Nick Desaulniers
2020-03-06 17:25 ` Joe Perches
2020-03-06 18:38 ` Joe Perches
2020-03-06 19:02 ` Nick Desaulniers
2020-03-06 19:10 ` Joe Perches
2020-03-07 0:07 ` linux-kernel: Unused static inline functions Joe Perches
2020-04-23 18:57 ` Nick Desaulniers
2020-04-23 21:22 ` Joe Perches
2020-04-24 16:07 ` Julia Lawall [this message]
2020-11-29 23:56 ` Joe Perches
2020-05-09 13:12 ` [PATCH] sched/cputime: silence a -Wunused-function warning Qian Cai
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=alpine.DEB.2.21.2004241806220.2344@hadrien \
--to=julia.lawall@inria.fr \
--cc=clang-built-linux@googlegroups.com \
--cc=error27@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ndesaulniers@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome