On Sat, 24 Mar 2007, Pawe? Wla? wrote:
So, it does work fine with Slackware 11 and kernel 2.2.20.2 (and by
implication and Pawel's testing Slack 11 and kernel 2.2.18). Kernel
Actually - 2.6.18, I never said it is 2.2.18 :)
Sorry, a typo, of course I meant 2.2.18.
No John, I think you put it quite wrong. Patrick V. gives you sources of
kernel, together with kernel includes, headears etc and with a lot of
precompiled kernels. You can of course compile your own kernel if
distribution kernels do not fit your needs, that should not be a
problem. BUT, if you change kernel sources (as you switch to 2.6.20
which is not included in Slackware 11.0) than not everything should go
so smoothly. It is YOU that start doing something non-standard (like
switching to 2.6.20 kernel). I do not say it is bad, as I also like
playing with different kernels, but you can complain on doing that
nonstandard things on Slackware (which is really great OS) only if you
are sure, that you would have problems dealing with kernel sources and
headers from Slackware 11.0 distribution.
I think you're wrong here - read the stuff in the thread over
again, particularly the piece from Linus sent by Patrick. According to
Linus, the userspace programs should link to the headers for the glibc
that system was compiled for, whereas modules and new kernels should be
compiled and linked against the kernel headers. In theory, you should be
able to have a kernel that differs in version from your userspace programs
- i.e. there should be a real separation between userspace and kernel
space.
The martian_modem compile fails at the linking stage - the kernel
module compiles fine with different headers being in /usr/include because
the kernel module makefile correctly) looks in the kernel tree. i.e. in a
perfect world kernel modules compile against the kernel /include and
userspace programs compile against the /usr/include which can legitimately
be different.
However, the devil is in the details. The question is, is there
really that separation that is logically desired according to Linus's
theory?
This may be a deep problem - but whichever way you cut it, either
you're wrong or Linus is wrong. Specifically, Linus stated it is *wrong*
to symlink /usr/include into the kernel tree.
I am glad you have you modem working now!
You and me both.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|message from the cookie daemon|
You're internalizing your irritation lately, which is causing
you to explode at people who jostle you, glare angrily at people
dressed in lame garb and bite your friend's head off for asking
stupid questions.
--
John Pate <johnny@xxxxxxxxxx>
Edinburgh, Scotland (home PC)
Disclaimer: I've probably changed my opinions by the time you read this
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
