lkml.org 
[lkml]   [2005]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectKernel header policy
It has been more than a week now...

+----------------------------------+-----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and | fax: 1-780-492-1729 |
| Communications Technologies | email: tsi@ualberta.ca |
| 352 General Services Building +-----------------------------------+
| University of Alberta | |
| Edmonton, Alberta | Standard disclaimers apply |
| T6G 2H1 | |
| CANADA | |
+----------------------------------+-----------------------------------+
XFree86 developer and VP. ATI driver and X server internals.

---------- Forwarded message ----------
Date: Sun, 3 Jul 2005 11:12:03 -0600 (MDT)
From: Marc Aurele La France <tsi@ualberta.ca>
To: Linus Torvalds
Subject: Kernel header policy

Hi, Linus. It has been a while since we last talked. I hope all is well
with you and your family.

I am contacting you to express my concern over a growing trend in kernel
development. I am specifically referring to changes being made to kernel
headers that break compatibility at the userland level, where __KERNEL__
isn't #define'd.

The most common errors involve the introduction of references, in
non-__KERNEL__ code, to symbols that ...

1) are only #define'd or typedef'ed in __KERNEL__-bracketed code; and/or
2) are non-ANSIC C99'isms.

Recent examples include, but are not limited to, ...

a) <linux/fb.h> was temporarily broken during 2.6.9's development cycle.
The problem here (fixed before 2.6.9's release) was an #include of
<linux/list.h> not bracketed by __KERNEL__. i.e. "1)" above.

b) <linux/pci.h> has been broken since 2.5.62's development cycle and has
yet to be fixed. Here, the #include of <linux/mod_devicetable.h> needs
to be bracked by __KERNEL__. This is another occurrence of "1)".

c) <linux/joystick.h> is broken in both ways by 2.6.13-rc1. This change
introduces references to <asm/types.h> symbols BITS_PER_LONG (only
#define'd under __KERNEL__), and __s64 (on 32-bit platforms, only
typedef'ed under gcc without -ansi).

It is understandable that such errors do not usually show up during kernel
development. Yet, an unfortunate consequence of the policy against
/usr/include/{linux,asm,...} symlinks is to delay detection of such errors
until someone attempts to rebuild an X server, or some other software,
with a glibc re-generated using the modified kernel headers.

It is certainly possible to report such problems individually and have
done so for most of them. But, in practice, it has sometimes been
difficult to determine who to contact, let alone convince the relevant
party that there is a problem. Furthermore, repetition over time turns
the reporting of such errors into an exercise in evangelisation, a
function I feel would be more effectively provided internally within the
kernel development community.

To that end, I would propose, as a possible technical solution, extending
the kernel build process to detect these errors during kernel development.

Your thoughts on this matter would be greatly appreciated.

Thanks.

Marc.

+----------------------------------+-----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and | fax: 1-780-492-1729 |
| Communications Technologies | email: tsi@ualberta.ca |
| 352 General Services Building +-----------------------------------+
| University of Alberta | |
| Edmonton, Alberta | Standard disclaimers apply |
| T6G 2H1 | |
| CANADA | |
+----------------------------------+-----------------------------------+
XFree86 developer and VP. ATI driver and X server internals.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-07-11 23:51    [W:0.072 / U:0.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site