Messages in this thread | | | Date | Tue, 17 Nov 1998 12:03:15 +0100 (MET) | From | (Guest section DW) | Subject | Re: include file conflict |
| |
From tytso@ATHENA.MIT.EDU Tue Nov 17 05:00:25 1998
Date: Tue, 17 Nov 1998 00:34:50 +0100 (MET) From: dwguest@win.tue.nl (Guest section DW)
But as I have been pointing out, auto-taking the most recent kernel version has at least two disadvantages: (1) it doesnt compile, (2) if it compiles, you find that your program suddenly is broken.
No, you're wrong.
It works if (a) the kernel the header file is carefully constructed to ...
It requires some discipline on the part of the kernel programmer, but can be done.
Hmm, a peculiar answer. I quote historical facts, and you tell me that I am wrong and as corroboration mention a hypothetical future.
Quite frankly, I've been screwed worst by undisciplined changes in the header files provided by glibc than I ever have by undisciplined changes in the kernel header files.
And if the argument is that glibc programmers are somehow inherently better able to create backwards compatible header files than kernel programmers, all I can say is that I very much disagree with you.
No - you get carried away. You attack a strawman of your own invention.
The argument is that if you have private copies of kernel header files then they don't change without you noticing. If there is a mistake, it is your own.
The kernel changes too quickly. The number of public glibc versions per year is not too large. A careful developer can try to test his programs with the latest (even with all) public libc versions. It is not possible to test software with all glibc / kernel combinations. Nevertheless, as history has shown (maybe you promise me it will never happen again) changes in kernel headers cause programs not to compile, and if they compile, to fail mysteriously.
So, for stability, it is a very good idea not to have software depend on the kernel version it was compiled under.
Andries
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |