* [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
@ 2013-02-21 18:42 Anthony G. Basile
2013-02-21 18:49 ` Mike Gilbert
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Anthony G. Basile @ 2013-02-21 18:42 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
2013-02-21 18:42 [gentoo-dev] Building against /usr/src/linux and linux-info.eclass Anthony G. Basile
@ 2013-02-21 18:49 ` Mike Gilbert
2013-02-21 21:25 ` Markos Chandras
2013-02-21 23:12 ` [gentoo-dev] " Doug Goldstein
2013-02-21 23:50 ` Maxim Kammerer
2 siblings, 1 reply; 7+ messages in thread
From: Mike Gilbert @ 2013-02-21 18:49 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
2013-02-21 18:49 ` Mike Gilbert
@ 2013-02-21 21:25 ` Markos Chandras
2013-02-21 22:05 ` [gentoo-dev] " Duncan
0 siblings, 1 reply; 7+ messages in thread
From: Markos Chandras @ 2013-02-21 21:25 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [gentoo-dev] Re: Building against /usr/src/linux and linux-info.eclass
2013-02-21 21:25 ` Markos Chandras
@ 2013-02-21 22:05 ` Duncan
0 siblings, 0 replies; 7+ messages in thread
From: Duncan @ 2013-02-21 22:05 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
2013-02-21 18:42 [gentoo-dev] Building against /usr/src/linux and linux-info.eclass Anthony G. Basile
2013-02-21 18:49 ` Mike Gilbert
@ 2013-02-21 23:12 ` Doug Goldstein
2013-02-21 23:46 ` Anthony G. Basile
2013-02-21 23:50 ` Maxim Kammerer
2 siblings, 1 reply; 7+ messages in thread
From: Doug Goldstein @ 2013-02-21 23:12 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
2013-02-21 23:12 ` [gentoo-dev] " Doug Goldstein
@ 2013-02-21 23:46 ` Anthony G. Basile
0 siblings, 0 replies; 7+ messages in thread
From: Anthony G. Basile @ 2013-02-21 23:46 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
2013-02-21 18:42 [gentoo-dev] Building against /usr/src/linux and linux-info.eclass Anthony G. Basile
2013-02-21 18:49 ` Mike Gilbert
2013-02-21 23:12 ` [gentoo-dev] " Doug Goldstein
@ 2013-02-21 23:50 ` Maxim Kammerer
2 siblings, 0 replies; 7+ messages in thread
From: Maxim Kammerer @ 2013-02-21 23:50 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-02-21 23:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-21 18:42 [gentoo-dev] Building against /usr/src/linux and linux-info.eclass Anthony G. Basile
2013-02-21 18:49 ` Mike Gilbert
2013-02-21 21:25 ` Markos Chandras
2013-02-21 22:05 ` [gentoo-dev] " Duncan
2013-02-21 23:12 ` [gentoo-dev] " Doug Goldstein
2013-02-21 23:46 ` Anthony G. Basile
2013-02-21 23:50 ` Maxim Kammerer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox