Search Linux Wireless

Re: [PATCH 28/44] compat: avoid using `#include_next' directive in compat headers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, Nov 22, 2010 at 9:32 PM, Luis R. Rodriguez
<lrodriguez@xxxxxxxxxxx> wrote:
> On Mon, Nov 22, 2010 at 6:19 PM, Arnaud Lacombe <lacombar@xxxxxxxxx> wrote:
>> Hi,
>>
>> On Mon, Nov 22, 2010 at 1:09 PM, Luis R. Rodriguez
>> <lrodriguez@xxxxxxxxxxx> wrote:
>>> On Sun, Nov 21, 2010 at 5:36 PM, Arnaud Lacombe <lacombar@xxxxxxxxx> 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
>>> <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.
>> 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 ? 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.

 - Arnaud
--
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


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux