Re: [GIT PULL] pin control bulk changes for v4.16

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Feb 5, 2018 at 10:27 AM, Julia Lawall <julia.lawall@xxxxxxx> wrote:
> On Mon, 5 Feb 2018, Linus Walleij wrote:

>> We definitely need some better tooling to find these things,
>> using Ingo's head and your occasional frustration is not going to
>> scale.
>>
>> Julia: do you have ideas on tooling that can loosen #include
>> deps and advise on when to replace #includes with forward
>> declarations of structs (etc) to bring down rebuild-triggering
>> dependencies?
>
> 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?
>
> 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?

Usually (in my limited experience, le's see what Ingo and Torvalds
say) the problem manifests mainly in include files including other
include files.

So say <linux/foo.h>:

#include <linux/bar.h>

struct foo {
   struct bar *barp;
};

Since this is only putting a pointer inside its struct and doesn't
need the information on the whole structs, as the size of a pointer
is well known we can reduce it to:

struct bar;

struct foo {
   struct bar *barp;
};

And thus as <linux/bar.h> is not even included, it can change
all it wants, our foo.h include file is not affected, neither will
any driver just casually #including <linux/foo.h> need to be
rebuilt.

This type of case (and variations on this theme) is the reason
we put a bunch of forward-declarations in kernel .h-files
just to break dependencies to stuff just referenced by pointer.

There is a counter-pattern saying "files should #include the
headers prototypes, structs (etc) it uses" that drives a truck
through this approach. But IMO when done properly, this
forward-declaring approach is quite readable.

I have very limited idea of where, whether in the preprocessor
or the compiler itself, the decision to treat struct bar *barp
as "just some pointer" happens, but it is a real neat trick, the
dependency chain is broken in CPP AFAICT anyways, and cuts
down the rebuilds.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html