Return-path: Received: from mail-iw0-f174.google.com ([209.85.214.174]:62566 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750790Ab0KWDWt (ORCPT ); Mon, 22 Nov 2010 22:22:49 -0500 Received: by iwn38 with SMTP id 38so798205iwn.19 for ; Mon, 22 Nov 2010 19:22:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1289355626-25373-1-git-send-email-lacombar@gmail.com> <1289355626-25373-29-git-send-email-lacombar@gmail.com> <20101110222448.GG4667@tux> From: "Luis R. Rodriguez" Date: Mon, 22 Nov 2010 19:22:28 -0800 Message-ID: Subject: Re: [PATCH 28/44] compat: avoid using `#include_next' directive in compat headers To: Arnaud Lacombe Cc: "linux-wireless@vger.kernel.org" , Luis Rodriguez Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Mon, Nov 22, 2010 at 6:40 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Nov 22, 2010 at 9:32 PM, Luis R. Rodriguez > wrote: >> On Mon, Nov 22, 2010 at 6:19 PM, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Mon, Nov 22, 2010 at 1:09 PM, Luis R. Rodriguez >>> wrote: >>>> On Sun, Nov 21, 2010 at 5:36 PM, Arnaud Lacombe wrote: >>>>> [...] >>>>> 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. >>> certainly :) >>> >>>> The >>>> purpose of the include_next was so that we can name our own >>>> 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. >>> I'm not sure to get what you mean by "we can avoid ifdef'ing all >>> includes for the same file on the upstream code", can you details ? >> >> Ah, that's right, you don't see or use compat-wireless likely. Ok, so >> what we do for backporting the 802.11 subsystem, Bluetooth and some >> Ethernet drivers is we take the stock upstream files, stuff them into >> a new directory, and then apply a series of patches to them to get the >> files to properly compile. The patches address all things that was not >> possible to backport through compat.git. Header file changes is one of >> the typical things we run into. If a new header file is added to newer >> kernels we can play a hack for older kernels and leave the code intact >> and introduce our own include/linux/foo.h through compat by prefering >> the local path over the kernel's path. If we're on newer kernels >> though include_next will go on the search path and find the kernel's >> own header file. >> > Is there any reason you want the compat's include directory to be > *before* the kernel include directory ? Hm, yeah but I forget why. It'll come to me. > Because just considering this > issue, if the kernel include directory was seen first, this would not > arise, as the compat-provided header would just be a fallback. True. Luis