> Well-written source compiles under all sufficiently recent libraries
> and functions under all sufficiently recent kernels, including
> those of next week.
Sure. Again, libc5 and glibc, linux 2.0 and 2.1. This makes linux appear
as 4 different os's with different requirements, on the SAME architecture.
What a maintenance pleasure. But what I am talking about, you should be
aware of this, being the mount maintainer.
Yes, I have struggled for a while, trying various configure scripts
but things are hopeless. It is absolutely necessary to have private
copies of the kernel includes.
One recent example: the program swapon.c needs the symbolic constants
SWAP_FLAG_PREFER and SWAP_FLAG_PRIO_MASK and SWAP_FLAG_PRIO_SHIFT.
These are gotten by including <sys/swap.h>, which includes <linux/swap.h>.
Bad! For, since recently, <linux/swap.h> also includes the definition of
union swap_header (which should be visible in user space, it is needed
by mkswap) which uses the constant PAGE_SIZE not defined anywhere in sight.
(Yes, in <asm/page.h>.)
Nobody could conjecture in advance that <linux/swap.h> would need <asm/page.h>.
[In fact, I think this was a rather unfortunate choice for union swap_header,
but that is a different discussion.]
> The kernel presents an API to the outside world.
> Whatever the kernel does internally is none of your business,
> and will change from week to week. But the API remains fairly
> stable, with features being added but not changed.
I take this as an argument for keeping copies of the header files with the
application: since the API is stable, the application won't break on newer
kernels even if when compiled with headers from older kernels.
Yes. That is precisely what I am saying.
That is the reason why glibc can move away from kernel headers.
Perhaps so, but perhaps not. This is a test that somebody with more time on their
hands should run.
There is nothing to be tested. It is true by definition. By aim.
If a kernel change breaks old stuff, then either it is a bug that
should be corrected, or it is on purpose, in which case the stuff
broken had better be something really ancient.
In practice not much is broken, otherwise we could not use glibc.
What I mean by sanitized: break headers into two halves, ...
An excellent idea. But this is not today's situation.
Maybe it can be next year's situation.
> Thus, (1) it is a good idea to improve the kernel sources a bit,
> but (2) you are wasting your time in the sense that a week
> or a month after you improved the includes something
> will be changed, and your programs will not compile anymore.
Fine, and the next day after I get a complaint, Linus will get a patch to
fix the headers. I prefer a "doesn't compile" error report, with a precise
reference to the place of the error, than a "doesn't work, whats wrong"
error report.
Yes, but your ideal is: works with Linux 2.2.X for X=0,1,2,5,6,7,8,11,12.
My ideal is: works with Linux 0.99 and all later kernels.
Fixing kernel headers when they break something will always leave some
versions where things are broken. With private copies nothing can be
broken.
[And you worry: but does that really work? It does, you just get a binary
that is independent of the kernel it was compiled under. Very worthwhile
for debugging and maintenance.
I recall the times where the declaration of some field in a struct was changed
from signed to unsigned. The program in question worked when compiled under an
old kernel, but failed silently when compiled under a new kernel. You see,
you are afraid of silent failures with private copies of the headers, but
the converse is true - you get silent failures when you don't have private
copies.]
> Indeed, most utilities from 1992 function fine today.
See hpa's reply.
I am not sure I agreed, answered him in private since Linux nostalgia
is again something that does not belong in this thread.
But yes, my claim is not some vague idea - many of my basic binaries
have a 1992 timestamp.
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/