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.1802051023540.3292@hadrien>
Date:   Mon, 5 Feb 2018 10:27:43 +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 Sat, Feb 3, 2018 at 1:51 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > On Fri, Feb 2, 2018 at 4:44 PM, Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> >>
> >> Stupid patch attached. I don't know how much this helps the insane
> >> dependency hell for <linux/pinctrl/devinfo.h>, but it's bound to help
> >> _some_.
> >
> > Testing it, that patch definitely cuts down on recompiles after
> >
> >      touch include/linux/pinctrl/devinfo.h
> >
> > a lot.
>
> Hey very nice. Sorry I was offline this weekend and didn't provide
> much feedback.
>
> Indeed it is smarter to forward-declare struct dev_pin_info.
>
> I rebuilt my platforms with the mainline and all is working just fine
> of course.
>
> > It still ends up rebuilding a fair amount of odd drivers, but now the
> > files it rebuilds at least make _some_ sense.
>
> Yeah :/
>
> I guess the lesson learned is that when I push stuff into device
> core like this, it needs to be done as exquisitely as cache-aligned
> structs because of the overall impact on the build systems.
>
> > One odd header include down. Ten million to go.
>
> Sorry about contributing to that :(
>
> 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. My
> subsystems had a few of those and it visibly impacted build
> time. As usual clean and consistent code is code that compiles
> quickly...
>
> 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?

julia