Hello, Victor!
> Do you really think it's right way to ask everyone to patch his(her)
> kernel headers ?
Not everyone. It's Ok to ask kernel maintainers and packagers of
distributions.
> > They might have already fixed the bug in 2.4.0-test6, though.
It's not fixed even in 2.4.0-test7-pre4
> 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 ?
I must disagree with Linus. Using kernel headers is good for having things
in one place. Also code reuse doesn't normally make the code worse.
> Situations where some structures EXPORTED TO USERSPACE (ioctl
> attributes, etc) are changed in stable branch are bugs and should be
> considered as such.
I agree with the statement above, but the standard way of exporting
structures in C is still by the means of header files. I don't think that
using Linux headers hides more bugs than it possibly discovers.
If a structure changes chances are that some programs will not compile. It
is much easier to find bugs at the compile time - you don't have to run
that exact line of code and scratch your head afterwards :-)
> 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.
My point was - string.h declares functions that are implemented in the
kernel itself. They are not available to any user programs, even those
linked against libc5. Hence they should not be visible to any user
programs.
If there is any opposition to fixing that particular bug in Linux then
GRUB should pull the definitions from the Linux headers. We don't want
another holy war.
Regards,
Pavel Roskin
