Bug 141318 - kernel headers leak kernel types
Summary: kernel headers leak kernel types
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Alpha 4
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Thorsten Kukuk
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-03 21:16 UTC by Robert Love
Modified: 2006-01-09 15:19 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
don't leak kernel types in ethtool.h (13.94 KB, patch)
2006-01-03 21:17 UTC, Robert Love
Details | Diff
don't leak kernel types in mii.h (610 bytes, patch)
2006-01-03 21:17 UTC, Robert Love
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Love 2006-01-03 21:16:30 UTC
<linux/mii.h> and <linux/ethtool.h> leak the kernel types u8, u16, u32, and u64 instead of using the user-space-friendly __u8, __u16, etc.

Aside from "don't pollute the user name space" this causes compilation failures as the types are only defined if __KERNEL__.

I submitted a patch to lkml but it probably won't be in the kernel we ship for 10.1.  I will attach it here.

In the meantime, this is causing compilation failures, so we need to fix it.  I don't know whether we prefer to patch this in the kernel or glibc -- either will work.
Comment 1 Robert Love 2006-01-03 21:17:04 UTC
Created attachment 61926 [details]
don't leak kernel types in ethtool.h
Comment 2 Robert Love 2006-01-03 21:17:23 UTC
Created attachment 61927 [details]
don't leak kernel types in mii.h
Comment 3 Robert Love 2006-01-04 19:00:42 UTC
FYI: Just checked, and Red Hat patches these files in their glibc.
Comment 4 Robert Love 2006-01-06 22:33:11 UTC
kukuk - by the looks of the changelog, you are the man wrt glibc.  ;-)

Can we get these two simple patches in?  I submitted fixes for the upstream kernel headers, but in the interim can we just fix the headers in our glibc?

Obviously, these files using those types is going to cause compilation issues...
Comment 5 Thorsten Kukuk 2006-01-08 09:07:02 UTC
(In reply to comment #4)
> kukuk - by the looks of the changelog, you are the man wrt glibc.  ;-)
> 
> Can we get these two simple patches in?  I submitted fixes for the upstream
> kernel headers, but in the interim can we just fix the headers in our glibc?
> 
> Obviously, these files using those types is going to cause compilation
> issues...

You always write about compilation issues without telling us which applications have problems.
No package in autobuild has problems with this and including kernel headers in userland applications is not supported by us. So I will not add this patches.

Comment 6 Robert Love 2006-01-08 15:57:15 UTC
Any application that uses mii.h or ethtool.h will have problems.  This includes ethtool and NetworkManager.  They both work because they are patched -- they self-define the kernel types u32, et al.

These headers are meant to be included in user-space applications: ALL they do is define a user-kernel interface.

The patches have already gone upstream (in 2.6-mm and now in Linus's git tree).

> including kernel headers in userland applications is not supported by us

Many glibc headers derive from the kernel and are intended for use by user-space.  These are but two examples.  What is not allowed is using kernel-only __KERNEL__ headers in user-space.  These do not fall in that category.
Comment 7 Thorsten Kukuk 2006-01-09 15:10:30 UTC
Correct, glibc headers are adjusted for inclusion in user-space, not the
other one.
Comment 8 Robert Love 2006-01-09 15:19:51 UTC
Sorry, I don't understand.

What "other one" ?