1 |
On Thu, Feb 21, 2013 at 1:42 PM, Anthony G. Basile |
2 |
<basile@××××××××××××××.edu> wrote: |
3 |
> Hi everyone, |
4 |
> |
5 |
> This issue has come up in a few bugs so I want to bounce it off the |
6 |
> community. When building packages that need a configured kernel source |
7 |
> tree, many ebuilds inherit linux-info to find configuration info about the |
8 |
> kernel. However, there is the running kernel with its configuration |
9 |
> (/proc/config.gz if it exists), there is the kernel source tree |
10 |
> (/usr/src/linux if it exists and is configured) and both of these can be of |
11 |
> a different version than linux-headers. Since building modules consumes |
12 |
> headers from /usr/include/linux, but uses code from /usr/src/linux and then |
13 |
> these modules are expected to insmod against the running kernel, all of |
14 |
> which can be mismatched, we have a lot of room for breakage. Eg. bug |
15 |
> #458014. |
16 |
> |
17 |
> Any ideas about how to deal cleanly with situations like that? |
18 |
> |
19 |
|
20 |
I'm no expert, but I always thought that modules are supposed to |
21 |
consume headers from the kernel source directory, not from |
22 |
/usr/include/linux. |
23 |
|
24 |
As well, the modules should be installed for whatever kernel version |
25 |
is present in /usr/src/linux (or KERNEL_DIR. This may be distinct from |
26 |
the currently running kernel. |
27 |
|
28 |
I think the headers in /usr/include/linux are there for building |
29 |
userspace programs, which would utilize the more stable userspace <-> |
30 |
kernel API. |