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] [day] [month] [year] [list]

Date:   Mon, 5 Feb 2018 14:08:51 -0500
From:   Paul Gortmaker <paul.gortmaker@...driver.com>
To:     Julia Lawall <julia.lawall@...6.fr>
CC:     Linus Walleij <linus.walleij@...aro.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        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

[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@...driver.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@...aro.org>
    Cc: Alexandre Courbot <gnurou@...il.com>
    Cc: linux-gpio@...r.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@...driver.com>
    Signed-off-by: Linus Walleij <linus.walleij@...aro.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