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

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

[Anthony G. Basile]

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
(716) 829-8197

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

[Mike Gilbert]

On Thu, Feb 21, 2013 at 1:42 PM, Anthony G. Basile
<basile@opensource.dyc.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?
>

I'm no expert, but I always thought that modules are supposed to
consume headers from the kernel source directory, not from
/usr/include/linux.

As well, the modules should be installed for whatever kernel version
is present in /usr/src/linux (or KERNEL_DIR. This may be distinct from
the currently running kernel.

I think the headers in /usr/include/linux are there for building
userspace programs, which would utilize the more stable userspace <->
kernel API.

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

[Markos Chandras]

On 21 February 2013 18:49, Mike Gilbert <floppym@gentoo.org> wrote:
> On Thu, Feb 21, 2013 at 1:42 PM, Anthony G. Basile
> <basile@opensource.dyc.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?
>>
>
> I'm no expert, but I always thought that modules are supposed to
> consume headers from the kernel source directory, not from
> /usr/include/linux.
>
> As well, the modules should be installed for whatever kernel version
> is present in /usr/src/linux (or KERNEL_DIR. This may be distinct from
> the currently running kernel.
>
> I think the headers in /usr/include/linux are there for building
> userspace programs, which would utilize the more stable userspace <->
> kernel API.
>

Yes, I think this is the case as well. I am not sure if modules use
the headers in /usr/include/linux. It feel wrong to me

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

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

[Duncan]

Markos Chandras posted on Thu, 21 Feb 2013 21:25:30 +0000 as excerpted:

>>> Eg. bug #458014.
>>>
>>> Any ideas about how to deal cleanly with situations like that?
>>>
>>>
>> I'm no expert, but I always thought that modules are supposed to
>> consume headers from the kernel source directory, not from
>> /usr/include/linux.

I believe I've read that somewhere quite authoritative (like LWN) as 
well.  Kernel modules, kernel sources.  Userspace, the cleaned up Linux-
headers.

In fact, there has been quite some kernel work recently (3.7 I believe, 
the commit log was heavy with related commits) done in ordered to make 
the separation cleaner.

>> As well, the modules should be installed for whatever kernel version is
>> present in /usr/src/linux (or KERNEL_DIR. This may be distinct from the
>> currently running kernel.

This problem is much worse with gentoo than with a typical binary distro 
that much more strictly controls both the kernel and headers shipped.  
AFAIK, that's one of the major reasons the eclass is there, to semi-
standardize both the handling and the relative priority of the various 
possibilities, but no solution's going to hit every corner-case, and if 
something's breaking on specific user's systems, in the end it's them 
that may have to either standardize their system (and build practices) to 
some degree, or handle their own breakage if they choose not to.

But userspace definitely should be using the installed linux-headers.  
And in-treeing kernel modules is STRONGLY encouraged upstream exactly due 
to this and other issues, to the point that while out-of-tree modules are 
tolerated as a fact of life, they're very much on a "the responsible dev 
(and users who choose to use his code) gets to keep his pieces" policy.  
That being the upstream policy, there's definitely limits on what gentoo 
can do to unbreak what upstream has already declared broken, too.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Doug Goldstein]

On Thu, Feb 21, 2013 at 12:42 PM, Anthony G. Basile
<basile@opensource.dyc.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
> (716) 829-8197
>

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.

-- 
Doug Goldstein

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@opensource.dyc.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
>> (716) 829-8197
>>
>
> 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
(716) 829-8197

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

[Maxim Kammerer]

On Thu, Feb 21, 2013 at 8:42 PM, Anthony G. Basile
<basile@opensource.dyc.edu> wrote:
> there is the kernel source tree
> (/usr/src/linux if it exists and is configured)

The kernel can also be split (KV_DIR + KV_OUT_DIR), with relevant
headers located in both directories. E.g., [1].

[1] https://bugs.gentoo.org/show_bug.cgi?id=424816

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte