Messages in this thread |  | | | Date | Sun, 15 Nov 1998 15:36:08 +0100 (MET) | | From | (Guest section DW) | | Subject | Re: include file conflict |
| |
From: Ion Badulescu <ionut@moisil.cs.columbia.edu>
> 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/
|  |