On Wed, Nov 01, 2006 at 09:41:20PM +0000, Paul wrote:
Hi Chris
On Wednesday 01 November 2006 21:21, cl@isbd.net wrote:
What seems to be the way is to do what I originally did which was to make a copy of /usr/linux/2.6.18 in /usr/linux/2.6.18.1 and then apply the 2.6.18.1 patch in the new area. Then you have to build the new kernel *twice*. You build it once and run it so you have a 2.6.18.1 kernel running, the second build then builds the 'custom' modules correctly (which fail in the first build).
Any third party kernel module that hard codes the kernel path to /lib/modules/`uname -r`/build and won't let you specify an alternative is severely broken (in my opinion). There *should*_always_ be a command line variable accepted so that a user can compile against a different kernel tree. How else would one expect to build for a different target kernel or even cross compile for a different architecture !
Yes, quite, and what happens if the module is needed for the kernel to run!
I think that ultimately the RTL8168 drivers will get incorporated into the kernel so that problem will go away.
The Vmware drivers are, no doubt, expecting to be added to an existing working system rather than being built as you are building a new kernel.
If you have to mess around building a kernel twice just for one driver, then either a bug report needs to be filed, or the h/w changed for something with a sane driver - Just my opinion of course ;-)
I think with the RTL8168 it's just that they're very new, as you know I had quite a few issues with the Abit AB9 Pro motherboard simply because it's so new.