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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081107080237.GB28847@logfs.org>
Date:	Fri, 7 Nov 2008 09:02:37 +0100
From:	Jörn Engel <joern@...fs.org>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Patch] Always include <linux/types.h>

On Wed, 5 November 2008 23:32:12 +0300, Alexey Dobriyan wrote:
> 
> If you are working on improving compile times, it's better concentrate
> on removing unneeded includes. If just removing "extern"s from prototypes
> can reliably save several seconds, reducing headers can do wonders.

My goal was more to assume we want all headers to compile standalone and
see where that would lead.  Result for include/linux/ was some 500 added
lines, 170 of which were to add types.h or compiler.h.  Another 50-100
further includes were fairly well-spread across the spectrum.  The
remainder was declarations like
struct super_block;

Overall we have three evils to choose from.  Headers with unresolved
dependencies lead to random compile breakage after removing a header
from some .c file.  Even if the change was tested, it can still break
for some config/architecture combination month down the line.

Sprinkling more includes throughout the headers increase compile time.
And the common practice of declaring a structure instead of including
the header is a pita when working with ctags.  The last problem is
particularly annoying since I have no idea what problem this warning is
supposed to solve:
In file included from include/linux/coda_cache.c:1:
include/linux/coda_cache.h:18: warning: ‘struct super_block’ declared inside parameter list
include/linux/coda_cache.h:18: warning: its scope is only this definition or declaration, which is probably not what you want

Should we just teach gcc to shut up about that one?

Jörn

-- 
Anything that can go wrong, will.
-- Finagle's Law
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ