Bug 141318

Summary:	kernel headers leak kernel types
Product:	[openSUSE] SUSE Linux 10.1	Reporter:	Robert Love <rml>
Component:	Basesystem	Assignee:	Thorsten Kukuk <kukuk>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	kukuk
Version:	Alpha 4
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	don't leak kernel types in ethtool.h don't leak kernel types in mii.h

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" ?