Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass

[Anthony G. Basile]

On 02/21/2013 06:12 PM, Doug Goldstein wrote:
> On Thu, Feb 21, 2013 at 12:42 PM, Anthony G. Basile
> <basile@××××××××××××××.edu> wrote:
>> Hi everyone,
>>
>> This issue has come up in a few bugs so I want to bounce it off the
>> community.  When building packages that need a configured kernel source
>> tree, many ebuilds inherit linux-info to find configuration info about the
>> kernel.  However, there is the running kernel with its configuration
>> (/proc/config.gz if it exists), there is the kernel source tree
>> (/usr/src/linux if it exists and is configured) and both of these can be of
>> a different version than linux-headers.  Since building modules consumes
>> headers from /usr/include/linux, but uses code from /usr/src/linux and then
>> these modules are expected to insmod against the running kernel, all of
>> which can be mismatched, we have a lot of room for breakage.  Eg. bug
>> #458014.
>>
>> Any ideas about how to deal cleanly with situations like that?
>>
>> --
>> Anthony G. Basile, Ph. D.
>> Chair of Information Technology
>> D'Youville College
>> Buffalo, NY 14201
>> [phone]
>>
>
> Kernel modules never use /usr/include/linux. That's the uapi headers,
> which are now broken out in 3.7 and newer. Kernel modules always use
> /usr/src/linux.
>
> There have been a number of issues with the differences between the
> user space bits and the kernel space bits wrt to netfilter post 3.0,
> so its not surprising that a userspace component is trying to use
> /usr/include/linux to frame up a structure to pass into kernel space
> via netlink and running into an issue.
>
> This is one of the reasons behind kapi/uapi to make it clear you
> shouldn't play with or touch this field/structure/value from user
> space.
>

I'm not sure the separation is so clean.  I know userland should only 
use /usr/include/linux, but modules could source both indirectly via an 
include from /usr/include/linux [1].

But there's still the issue between the running kernel and 
/usr/src/linux?  In the eclass, linux_config_path() first tries to find 
/usr/src/linux/.config and then falls back on /proc/config.gz.  This is 
too hackly since packages building kernel modules could use the wrong 
config file.


Ref.

[1] Take a look at Pablo's rewrite of a patch I submitted to get 
<linux/netfilter_ipv4/nf_nat.h> into the kernel:

    http://www.spinics.net/lists/netfilter-devel/msg19833.html

There he includes in <linux/netfilter_ipv4/nf_nat.h>

    /usr/src/linux/include/net/netfilter/nf_conntrack_tuple.h

So even though the later is kapi, the division from uapi is not so clean.



-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]