From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
<linux-gpio@vger.kernel.org>
Subject: Re: [GIT PULL] pin control bulk changes for v4.16
Date: Mon, 5 Feb 2018 14:08:51 -0500 [thread overview]
Message-ID: <20180205190851.GD20138@windriver.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1802051023540.3292@hadrien>
[Re: [GIT PULL] pin control bulk changes for v4.16] On 05/02/2018 (Mon 10:27) Julia Lawall wrote:
>
>
> On Mon, 5 Feb 2018, Linus Walleij wrote:
>
[...]
> >
> > Another thing that comes to mind was Paul Gortmaker's tedious
> > work to remove #include <linux/module.h> from drivers that cannot
> > be built as modules that happened in the last few months.
I also took aim at headers including giant headers ; see below.
[...]
> Could you explain more? Is the point that you want to remove an include
> but it has one declaration that you need, and so you want to bring it down
> into the .c file? Would the need for that actually indicate that the
> include file is designed incorrectly?
I put a bit of an explanation in this commit:
commit d47529b2e9fe0ec2eb1f072afad8849f52e385c4
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon Sep 12 18:16:31 2016 -0400
gpio: don't include module.h in shared driver header
Most shared headers in include/linux don't need to know what the
internals of a struct module are; all they care about is that it
is a struct and hence they may require a pointer to one.
The advantage in this is that module.h is including a lot of stuff
itself, and an otherwise empty C file that just contains module.h
will result in ~750kB from CPP (compared to say 12kB from init.h)
So we have approximately 50 instances of "struct module;" in the
various include/linux headers already that help us keep module.h
out of other headers; here we do the same for gpio.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I'm sure I've got more of these type of commits sitting around locally,
unfortunately there have been other "interesting" things going on in the
linux world in the last month that have prevented me from touching any
of them. :-/
Paul.
--
>
> Can one assume that each include is self contained, ie it includes the
> things that it needs and does not rely on the .c file having included
> other things beforehand?
>
> julia
next prev parent reply other threads:[~2018-02-05 19:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-02 13:28 [GIT PULL] pin control bulk changes for v4.16 Linus Walleij
2018-02-02 22:56 ` Linus Torvalds
2018-02-03 0:44 ` Linus Torvalds
2018-02-03 0:51 ` Linus Torvalds
2018-02-05 9:20 ` Linus Walleij
2018-02-05 9:27 ` Julia Lawall
2018-02-05 9:42 ` Linus Walleij
2018-02-05 9:58 ` Julia Lawall
2018-02-05 19:08 ` Paul Gortmaker [this message]
2018-02-03 10:45 ` Ingo Molnar
2018-02-05 10:09 ` David Laight
2018-02-05 16:55 ` Linus Torvalds
2018-02-05 17:19 ` Linus Torvalds
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=20180205190851.GD20138@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=gregkh@linuxfoundation.org \
--cc=julia.lawall@lip6.fr \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox