On 15 Dec 00 at 10:23, Dana Lacoste wrote:
> > On Fri, Dec 15, 2000 at 12:14:04AM +0000, Miquel van Smoorenburg wrote:
>
> > 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)
>
> 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]
> 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
Dana Lacoste wrote:
>
> > 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 :)
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)
On Fri, 15 Dec 2000, Petr Vandrovec wrote:
> On 15 Dec 00 at 10:23, Dana Lacoste wrote:
> > > On Fri, Dec 15, 2000 at 12:14:04AM +0000, Miquel van Smoorenburg wrote:
> >
> > > 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)
> >
> > 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.
On Fri, Dec 15, 2000 at 09:31:57AM -0800, [email protected] wrote:
> > 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
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< come and join the fun >>>>>>>>>>>>
On Fri, 15 Dec 2000, Ingo Oeser wrote:
> On Fri, Dec 15, 2000 at 09:31:57AM -0800, [email protected] wrote:
> > > 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.
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?
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>.
On Sat, 16 Dec 2000, Keith Owens wrote:
> 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?
[[email protected]]
> 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
On Sat, 16 Dec 2000, Peter Samuelson wrote:
>
> [[email protected]]
> > 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.
> 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.
> 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.
You are assuming there is a /usr/src/linux that came pre-installed. This
is not a valid assumption.
[[email protected] <[email protected]>]
> 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
On Sun, 17 Dec 2000, Peter Samuelson wrote:
>
> [[email protected] <[email protected]>]
> > 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?
[[email protected]]
> One last question: WHY is the kernel's top-level Makefile handling
> this symlink?
Where do you think it should be handled? 'make modules_install' seems
like the most logical place, to me.
Peter
On Sun, 17 Dec 2000, Peter Samuelson wrote:
>
> [[email protected]]
> > One last question: WHY is the kernel's top-level Makefile handling
> > 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.