Linus's include file strategy redux
Quoted 9 lines · Dana Lacoste
Quoted 4 lines · Miquel van Smoorenburg
It's the version that's in cvs, I just did an cvs update. It's been in it for ages. If it's wrong, someone *please* correct it.
I think this is the important part.
This subject has come up quite a few times in the past couple of weeks on the scyld (eepro/tulip) mailing lists.
Quoted 7 lines
Essentially, whatever solution is implemented MUST ensure :
1 - glibc will work properly (the headers in
/usr/include/*don't
change in an incompatible manner)2 - programs that need to compile against the current kernel MUST
be able to do so in a quasi-predictable manner.
Maybe you did not notice, but for months we have /lib/modules/uname -r/build/include, which points to kernel headers, and which should be used for compiling out-of-tree kernel modules (i.e. latest vmware uses this).
If you want to use some linux-specific feature in your program, you have two choices: (1) use standard <linux/xxx.h> from version which came with glibc, or (2) create your personal copy of known-to-work xxx.h. Using anything else (such as latest version of xxx.h) is known to not work, and brokes very often. Compare existing headers between 1.2.0 and 2.4.0. They are - hmm - a bit different. Also, what if user currently has installed 2.2.x kernel, but in future it will want to use 2.4.x, with its new features. You have to recompile all programs because of they were compiled with old kernel headers? No.
[And for example, with ncpfs you just cannot create version which works with 2.0/2.2/2.4 using kernel headers, as API changed during time completely. With private headers it is easy. You can also add support into userspace without modifying Linus kernel. And after some time you can swap API in kernel and no-one notices (modulo whether Linus will agree with change, but you can always ask in advance).]
Best regards,
Petr Vandrovec [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines
Maybe you did not notice, but for months we have
/lib/modules/uname -r/build/include, which points to kernel headers, and which should be used for compiling out-of-tree kernel modules (i.e. latest vmware uses this).
What about the case where I'm compiling for a kernel that I'm not running (yet)?
lm_sensors, for example, told me yesterday when I compiled it that I was running 2.2.17, but it was compiling for 2.2.18 (because I moved the symlink in /usr/src/linux to point to /usr/src/linux-2.2.18)
I personally wouldn't like some programs to do a uname -r check because it won't do what I want it to :)
--
Dana Lacoste
Linux Developer
Peregrine Systems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Dana Lacoste
Quoted 5 lines
Maybe you did not notice, but for months we have
/lib/modules/uname -r/build/include, which points to kernel headers, and which should be used for compiling out-of-tree kernel modules (i.e. latest vmware uses this).What about the case where I'm compiling for a kernel that I'm not running (yet)?
Quoted 7 lines
lm_sensors, for example, told me yesterday when I compiled it that I was running 2.2.17, but it was compiling for 2.2.18 (because I moved the symlink in/usr/src/linuxto point to/usr/src/linux-2.2.18)I personally wouldn't like some programs to do a
uname -rcheck because it won't do what I want it to :)
And don't forget cross-compiling... (No, I don't know how all that is supposed to work. *sigh*)
^C-ya,
Eli
--------------------. "To the systems programmer, users and applications
Eli Carter | serve only to provide a test load."
[email protected] `---------------------------------- (random fortune) -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 15 lines · Petr Vandrovec
Quoted 14 lines · Dana Lacoste
Quoted 4 lines · Miquel van Smoorenburg
It's the version that's in cvs, I just did an cvs update. It's been in it for ages. If it's wrong, someone *please* correct it.
I think this is the important part.
This subject has come up quite a few times in the past couple of weeks on the scyld (eepro/tulip) mailing lists.Essentially, whatever solution is implemented MUST ensure :
1 - glibc will work properly (the headers in
/usr/include/*don't
change in an incompatible manner)
Quoted 7 lines
Quoted 2 lines
2 - programs that need to compile against the current kernel MUST
be able to do so in a quasi-predictable manner.Maybe you did not notice, but for months we have
/lib/modules/uname -r/build/include, which points to kernel headers, and which should be used for compiling out-of-tree kernel modules (i.e. latest vmware uses this).
This symlink really should be a copy instead, because the finished kernel may be installed on a machine that does not have kernel source installed on it. Dangling symlinks are BAD.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · On Fri, Dec 15, 2000 at 09:31:57AM -0800, [email protected] wrote:
Quoted 4 lines
Maybe you did not notice, but for months we have
/lib/modules/uname -r/build/include, which points to kernel headers, and which should be used for compiling out-of-tree kernel modules (i.e. latest vmware uses this).This symlink really should be a copy instead, because the finished kernel may be installed on a machine that does not have kernel source installed on it. Dangling symlinks are BAD.
But if you compile for another machine, this copy is bad. It also takes to much time and space to create this copy.
I really disagree here.
Regards
Ingo Oeser
Signature · 6 lines
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< come and join the fun >>>>>>>>>>>>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/Quoted 6 lines · Ingo Oeser
Quoted 5 lines · On Fri, Dec 15, 2000 at 09:31:57AM -0800, [email protected] wrote:
Quoted 4 lines
Maybe you did not notice, but for months we have
/lib/modules/uname -r/build/include, which points to kernel headers, and which should be used for compiling out-of-tree kernel modules (i.e. latest vmware uses this).
Quoted 8 lines
Quoted 3 lines
This symlink really should be a copy instead, because the finished kernel may be installed on a machine that does not have kernel source installed on it. Dangling symlinks are BAD.
But if you compile for another machine, this copy is bad. It also takes to much time and space to create this copy.
I really disagree here.
Do you have an alternative reccomendation? I've shown where the symlink method WILL fail. You disagree that having the configured headers copied is a workable idea. What else is there?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · On Fri, 15 Dec 2000 19:37:49 -0800 (PST), [email protected] wrote:
Do you have an alternative reccomendation? I've shown where the symlink method WILL fail. You disagree that having the configured headers copied is a workable idea. What else is there?
Use the pcmcia-cs method. Ask where the kernel headers with a sensible default if the user just presses <ENTER>.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Keith Owens
Quoted 3 lines · On Fri, 15 Dec 2000 19:37:49 -0800 (PST), [email protected] wrote:
Do you have an alternative reccomendation? I've shown where the symlink method WILL fail. You disagree that having the configured headers copied is a workable idea. What else is there?
Use the pcmcia-cs method. Ask where the kernel headers with a sensible default if the user just presses <ENTER>.
Well yes, but can you ask the user non-interactively and get a sensible answer?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines
Do you have an alternative reccomendation? I've shown where the symlink method WILL fail. You disagree that having the configured headers copied is a workable idea. What else is there?
4.5 more megabytes, per kernel, on my root filesystem. (That's *after* pruning the extra include/asm-*/'s.) Thanks but no thanks.
Symlinks fail only if you move or delete your tree. By doing that, you have proven that you actually know what and where your kernel sources are, which in turn is strong evidence that you are not in need of those "External Module Compiling for Dummies" scripts.
Conversely, by actually trusting a random script to compile an external module unaided, the user is all but declaring himself incapable of messing around with the /usr/src/linux that came pre-installed.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Peter Samuelson
Quoted 3 lines
Do you have an alternative reccomendation? I've shown where the symlink method WILL fail. You disagree that having the configured headers copied is a workable idea. What else is there?
4.5 more megabytes, per kernel, on my root filesystem. (That's *after* pruning the extra include/asm-*/'s.) Thanks but no thanks.
Yep. Did not occur to me at the time I asked. Someone else pointed this out to me also. VERY good point, but still needed to be explicitely mentioned.
Quoted 4 lines
Symlinks fail only if you move or delete your tree. By doing that, you have proven that you actually know what and where your kernel sources are, which in turn is strong evidence that you are not in need of those "External Module Compiling for Dummies" scripts.
I have not moved or deleted a tree. I do not HAVE a kernel tree in the first place. Therefore, nothing for the symlink to point to when I install the kernel.
Quoted 3 lines
Conversely, by actually trusting a random script to compile an external module unaided, the user is all but declaring himself incapable of messing around with the
/usr/src/linuxthat came pre-installed.
You are assuming there is a /usr/src/linux that came pre-installed. This is not a valid assumption.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
[[email protected] <[email protected]>]
Quoted 3 lines
I have not moved or deleted a tree. I do not HAVE a kernel tree in the first place. Therefore, nothing for the symlink to point to when I install the kernel.
If this is not the machine you compile your kernels on, why are you compiling your external modules on it?
In any case, at the very least you need a copy of the appropriate kernel headers. Some distributions have packages for these to match their kernel image packages. If that's where you got yours, the packaging should have included the build/ symlink. If it doesn't, file a bug. And incidentally, also file one if the "kernel headers" package doesn't come with Makefile, Rules.make, arch/$ARCH/Makefile and .config . (Those four are very useful for getting your settings right when compiling external modules.)
If you installed the headers *without* any infrastructure support from a distribution, then once again I don't think you need "External Module Compiling for Dummies", and all of the above is *your* job.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Peter Samuelson
[[email protected] <[email protected]>]
Quoted 3 lines
I have not moved or deleted a tree. I do not HAVE a kernel tree in the first place. Therefore, nothing for the symlink to point to when I install the kernel.
If this is not the machine you compile your kernels on, why are you compiling your external modules on it?
One last question: WHY is the kernel's top-level Makefile handling this symlink?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines
One last question: WHY is the kernel's top-level
Makefilehandling this symlink?
Where do you think it should be handled? 'make modules_install' seems like the most logical place, to me.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · Peter Samuelson
Quoted 2 lines
One last question: WHY is the kernel's top-level
Makefilehandling this symlink?Where do you think it should be handled? 'make
modules_install' seems like the most logical place, to me.
I think making the symlink should be handled outside the proper scope of the top-level Makefile, for reasons I have brought up earlier in this discussion; The Makefile is simply not equipped to know the full state of the system it is being run for outside the simple case of one single machine.
s/WHY is/For which specific reasons is/
Anyway, the associated discussions cleared up nearly all the technical-related questions I had. The remaining questions relate toward policy-issues orthogontal to implementation details. I am still a little unclear on the nature of the problem this symlink is meant to solve.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/