Re: whose job is it to include various header files?
- From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
- Date: Fri, 14 Mar 2008 05:29:54 -0400 (EDT)
On Fri, 14 Mar 2008, Robert P. J. Day wrote:
On Fri, 14 Mar 2008, mws@xxxxxxxxxxxxxxxxxx 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
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- whose job is it to include various header files?
- From: Robert P. J. Day
- Re: whose job is it to include various header files?
- From: Jesper Juhl
- Re: whose job is it to include various header files?
- From: mws
- Re: whose job is it to include various header files?
- From: Robert P. J. Day
- whose job is it to include various header files?
- Prev by Date: Re: [PATCH -mm crypto] AES: remove crypto_fl_tab and replace crypto_il_tab with isb_tab
- Next by Date: Re: [ANNOUNCE] Ramback: faster than a speeding bullet
- Previous by thread: Re: whose job is it to include various header files?
- Next by thread: [PATCH] ibmpex: Report temperatures in mC, not C.
- Index(es):
Relevant Pages
|
Loading
