| 1 |
On Thu, Feb 21, 2013 at 12: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 |
> Anthony G. Basile, Ph. D. |
| 21 |
> Chair of Information Technology |
| 22 |
> D'Youville College |
| 23 |
> Buffalo, NY 14201 |
| 24 |
> (716) 829-8197 |
| 25 |
> |
| 26 |
|
| 27 |
Kernel modules never use /usr/include/linux. That's the uapi headers, |
| 28 |
which are now broken out in 3.7 and newer. Kernel modules always use |
| 29 |
/usr/src/linux. |
| 30 |
|
| 31 |
There have been a number of issues with the differences between the |
| 32 |
user space bits and the kernel space bits wrt to netfilter post 3.0, |
| 33 |
so its not surprising that a userspace component is trying to use |
| 34 |
/usr/include/linux to frame up a structure to pass into kernel space |
| 35 |
via netlink and running into an issue. |
| 36 |
|
| 37 |
This is one of the reasons behind kapi/uapi to make it clear you |
| 38 |
shouldn't play with or touch this field/structure/value from user |
| 39 |
space. |
| 40 |
|
| 41 |
-- |
| 42 |
Doug Goldstein |
Archives