mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: mws@twisted-brains.org
Cc: Jesper Juhl <jesper.juhl@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: whose job is it to include various header files?
Date: Fri, 14 Mar 2008 05:29:54 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.1.00.0803140518300.4434@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.1.00.0803140405510.3148@localhost.localdomain>

On Fri, 14 Mar 2008, Robert P. J. Day wrote:

> On Fri, 14 Mar 2008, mws@twisted-brains.org wrote:
>
> > what i said in my first sentence is the imho proper way: if you
> > alter sources and includes get obsolete, remove them and fix
> > compiling again for files that formerly depended (implicit or
> > explicit) on this altered sources. not to much work for the
> > developer himself and also not exhausting the compile times.
>
> and, in my defense, that's what i *thought* i was doing, not having
> noticed that one of those "unnecessary" #includes really was
> required after all.  argh.  that was embarrassing.

  sure, let's beat this to death.

  upon reflection, i realize i was trying to deal with two different
issues.  on the one hand, there are the (countless?) header files that
don't include header files they normally should.  for instance,
imagine a file fubar.c that contains:

  ...
  #include <linux/percpu.h>
  ...
  ... some reference to GFP_KERNEL ...
  ...

but doesn't include <linux/gfp.h>, which it should 'cuz it's referring
to GFP_KERNEL.  the above will still work since percpu.h includes
slab.h, which includes gfp.h, so it all works out in the end.  and
there's simply too much of that going on to do anything about.

on the other hand, something that *is* worth fixing is what's in
percpu.h right now:
  ...
  #include <linux/string.h> /* For memset() */
  ...

since it's clear(?) that percpu.h has no need for string.h, it does
make sense to remove that include and see if that causes the build to
break because others have quietly been taking advantage of that
include.

  IMHO, then, that second case is worth trying to fix when it comes
up.  the first really isn't, but i had the two confused and thought i
had actually come across the second example.  again, my stupidity.

rday

p.s.  just for fun, i did remove that include of string.h from
percpu.h and i'm doing an allyesconfig x86 build off on the side just
to see the result.  if it still builds, then that *would* be worth a
quick patch, just to stop including stuff you don't need.  and there's
going to be *lot* less of that, i would think.

--


========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================

      reply	other threads:[~2008-03-14  9:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-13 22:09 Robert P. J. Day
2008-03-13 22:46 ` Randy Dunlap
2008-03-13 23:53 ` Jesper Juhl
2008-03-14  1:02   ` Robert P. J. Day
2008-03-14  1:36   ` Jan Engelhardt
2008-03-14  1:53     ` Robert P. J. Day
2008-03-14  5:47       ` Alexey Dobriyan
2008-03-14  8:01         ` Robert P. J. Day
2008-03-14  6:47   ` mws
2008-03-14  8:07     ` Robert P. J. Day
2008-03-14  9:29       ` Robert P. J. Day [this message]

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=alpine.LFD.1.00.0803140518300.4434@localhost.localdomain \
    --to=rpjday@crashcourse.ca \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mws@twisted-brains.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®