15-Aug-00 12:47 you wrote:
> From: Andres VHNet Staff <[EMAIL PROTECTED]>
> Subject: Re: problems w/ linux 2.4.0-testX and reiserfs 3.6.11
> Date: Mon, 14 Aug 2000 21:02:26 -0400
>> Oops, sorry about that. i wanted to keep the email short, i thought i posted
>> the errors as well ;) Anyways, here's the rest:
> I think this is the same bug as Pavel reported.
Exactly.
> Please search his patch for Linux in the mail archive.
Do you really think it's right way to ask everyone to patch his(her)
kernel headers ?
> They might have already fixed the bug in 2.4.0-test6, though.
Do not count for it. Somethimes such fixes slip in but this is EXCEPTIONS
not rule. Rule is simple: "any program which tries to include kernel headers
directly is broken and deserve to lose". It official Linus's position and
he stated it quite a few times (serach lkml archives for more info). Why ?
It's simple: kernel API is designed to be BINARY-level compatible, NOT
source-level compatible (unlike userspace libraries). Kernel headers are just
that: kernel headers. They are NOT intended for userspace programs. But what
if I need some structure defined only in kernel headers and not yet exported
by GLibC ? It's easy: pull definitions out of kernel headers and bundle it
with your program. Sometimes it can be automated with scripts, sometimes it's
better to do by hand. If kernel headers or kernel internals will change then
either:
1. Binary compatibility will be in place and your program should not be modified
or:
2. Changes are deep and wide (like ipchains => netfilter change) and you
should change your program anyway and just new structures from new kernel
headers will not save you -- in such case you can repull definitions from
kernel headers again.
Situations where some structures EXPORTED TO USERSPACE (ioctl attributes, etc)
are changed in stable branch are bugs and should be considered as such.
This is more or less summary of Linus's position on "my program with
#include <linux/blah-blah-blah.h> is broken with kernel x.y.z" subject.
Such "fixes" are duscussed @ lkml every month or so and Linus usually rejects
them in the end.
P.S. You can ask: why there are __KERNEL__ checks in kernel headers at all ?
Answer: legacy programs based on libc5. Linux kernel STILL tries to be
compatible with such legacy programs. But new programs SHOULD NOT include
kernel headers as stated above.
