On Sun, Nov 21, 2010 at 5:36 PM, Arnaud Lacombe <lacombar@xxxxxxxxx> wrote: > Hi, > > On Wed, Nov 10, 2010 at 5:24 PM, Luis R. Rodriguez > <lrodriguez@xxxxxxxxxxx> wrote: >> On Tue, Nov 09, 2010 at 06:20:10PM -0800, Arnaud Lacombe wrote: >>> Signed-off-by: Arnaud Lacombe <lacombar@xxxxxxxxx> >>> --- >>> Âinclude/linux/pm_qos_params.h |  Â7 +++---- >>> Âinclude/linux/tracepoint.h  Â|  14 +++++++------- >>> Âinclude/net/net_namespace.h  |  14 +++++++------- >>> Âinclude/trace/define_trace.h Â|  Â5 ----- >>> Â4 files changed, 17 insertions(+), 23 deletions(-) >>> >>> diff --git a/include/linux/pm_qos_params.h b/include/linux/pm_qos_params.h >>> index e1f083c..8c69ab2 100644 >>> --- a/include/linux/pm_qos_params.h >>> +++ b/include/linux/pm_qos_params.h >>> @@ -1,8 +1,7 @@ >>> Â#include <linux/version.h> >>> >>> -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,25)) >>> -#include_next <linux/pm_qos_params.h> >>> -#else >>> +#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,25)) >>> + >> >> But will the kernels' own pm_qos_params.h be included for kernels >= 2.6.25? >> > The compat headers should be at the end of the include list, so that > the kernel headers get included first, and the compat one will only be > when the kernel does not provide the header. This is the only sane way > to override kernel provided stuff. That said, there is certainly a > use-case I missed. Agreed, but you are missing the purpose of the trick used here. The purpose of the include_next was so that we can name our own <linux/pm_qos_params.h> which is part of compat and these directories *will* get a priority over the kernel's so that way we can avoid ifdef'ing all includes for the same file on the upstream code. Without an include_next we'd simply skip including the kernel's own original header file. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
