All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: christoph.paasch@uclouvain.be
Cc: Randy Dunlap <rdunlap@xenotime.net>,
	davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
Date: Sun, 09 Jan 2011 21:55:41 +0000	[thread overview]
Message-ID: <1294610141.2823.31.camel@localhost> (raw)
In-Reply-To: <201101092232.19171.christoph.paasch@uclouvain.be>

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.


  reply	other threads:[~2011-01-09 21:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-09 20:55 [PATCH] Cleanup include/net/tcp.h include-files and coding-style Christoph Paasch
2011-01-09 21:06 ` Randy Dunlap
2011-01-09 21:32   ` Christoph Paasch
2011-01-09 21:55     ` Ben Hutchings [this message]
2011-01-09 22:33       ` Christoph Paasch
2011-01-09 23:06         ` Ben Hutchings
2011-01-10  9:03           ` Christoph Paasch
2011-01-10 11:11           ` Alexey Dobriyan
2011-01-10 11:44             ` Christoph Paasch
2011-01-10 12:12               ` Alexey Dobriyan
2011-01-10 15:50               ` Randy Dunlap
2011-01-10 16:24                 ` Christoph Paasch
2011-01-10 16:30                   ` Randy Dunlap
2011-01-10 17:02                     ` Alexey Dobriyan
2011-01-09 22:30 ` Alexey Dobriyan
2011-01-09 22:39   ` Christoph Paasch
2011-01-09 23:06     ` Christoph Paasch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1294610141.2823.31.camel@localhost \
    --to=bhutchings@solarflare.com \
    --cc=christoph.paasch@uclouvain.be \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.