linux-kernel - Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style

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: <1294610141.2823.31.camel@localhost>
Date:	Sun, 09 Jan 2011 21:55:41 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	christoph.paasch@...ouvain.be
Cc:	Randy Dunlap <rdunlap@...otime.net>, davem@...emloft.net,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Cleanup include/net/tcp.h include-files and
 coding-style

On Sun, 2011-01-09 at 22:32 +0100, Christoph Paasch wrote:
> Hello,
> 
> On Sunday, January 09, 2011 wrote Randy Dunlap:
> > On Sun,  9 Jan 2011 21:55:34 +0100 Christoph Paasch wrote:
> > If there is something in net/tcp.h that uses data or functions from
> > <linux/list.h>, then <linux/list.h> should be #included in net/tcp.h,
> > whether some other file pulls it in indirectly or not.
> > 
> > etc. etc. etc.
> Why?
> 
> IMHO I think that it increases compile-time.
> Ok, here in that case it only increases it slightly (probably it isn't even 
> measurable).

The cost of repeated inclusion is minimal.  GCC's preprocessor
recognises when the entire content of a file is conditional on #ifndef
FOO and will not even open it again if FOO is defined.

>  But, if *all* the files would be more strict in including, I'm 
> sure that it would make a difference.
> The less files you include, the faster the compilation will be.
> 
> In net/tcp.h there were even 4 unnecessary included files.
> 
> And, then we would also need to include:
> net/net_namespace.h (for struct net)
> 
> Also, I think that it makes the code more readable and also easier to 
> maintain. The more files we include, the bigger the chance is that we will end 
> up with plenty of files unnecessarily included, and thus the compile-time will 
> explode.

If a file directly references definitions that are supposed to be
provided by a certain header, changing it to rely on indirect inclusion
of that header generally does *not* aid maintenance.

(There are some cases where you should rely on indirect inclusion, such
as where <linux/foo.h> includes <asm/foo.h>.)

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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/