Re: Potentially serious problem with kernel-headers...
On 13 Jul 1998, Dale E. Martin wrote:
> Dale Scheetz <dwarf@polaris.net> writes:
>
> > If you "really" need to use 2.0.34 kernel headers for the package in
> > question, the correct way to get them is using the -I option on the
> > compiler command line, and include the specific headers from the desired
> > kernel.
> >
> > Luck,
> >
> > Dwarf
>
> As long as the binary produced will really work on all 2.0.x kernels, I
> guess this is an OK solution. But, I'm afraid this is going to be a common
> problem.
The problem actually originates because there is no defined, solid,
unchanging, interface to the kernel. It is libc's responsibility to offer
this "consistant" interface to the rest of the system, but libc depends on
consistancy in kernel headers in order to be capable of providing such.
There is currently a, sometimes heated, debate going on right now between
the kernel maintainers and the glibc maintainers about just how to deal
with this.
Distributions have been "dealing" with this problem for as long as I can
remember, and Debian's solution seems to lead to a more stable system in
general, while allowing for "special case" conditions where more specific
kernel headers are required. The consistancy of the distribution relies on
the correct choice of kernel headers for the range of kernels and packages
the distribution intends to support. We provide this by insisting on a
libc-dev that provides that consistancy. We must, however, rely on the
kernel to supply "backward" compatibility, and sometimes this just will
not happen. Those package so effected must depend on, and build with,
different headers than the rest of the distribution, and must be "watched"
much more closely than "normal" packages.
I encourage all maintainers with packages that fall into the catagory of
"special needs" from the kernel headers, take a close look as the programs
use of these "features" and see if you can get the same results throught
"more stable" system calls that do not require the knowledge of kernel
internals. (This seems to be the position Linus has taken, although I'm
not sure I completely understand his position...)
Feel free to coordinate with me, and be sure to communicate with the
author and get his feelings about the way things could work more kernel
independent.
Please note as well, I am not one who thinks that future kernel changes
will not happen, or that they will not effect applications level programs
when they do happen, but I do think that a lot more can be done to
insulate apps level code from kernel specific problems.
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: