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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1802051057120.3292@hadrien>
Date:   Mon, 5 Feb 2018 10:58:32 +0100 (CET)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     Linus Walleij <linus.walleij@...aro.org>
cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-gpio@...r.kernel.org
Subject: Re: [GIT PULL] pin control bulk changes for v4.16



On Mon, 5 Feb 2018, Linus Walleij wrote:

> On Mon, Feb 5, 2018 at 10:27 AM, Julia Lawall <julia.lawall@...6.fr> 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.

OK, thanks for the explanation.  It seems like a very interesting problem.
I will think about it and see if something can be done.  It seems like it
may need careful checking by a human, due to macros, ifdefs, etc, but
perhaps it can at least be heplful to narrow down the opportunities.

julia