Hi Chris
On Wednesday 01 November 2006 13:41, cl@isbd.net wrote:
What's the right/best way to patch the kernel to minimise these problems? I created /usr/src/linux-2.6.18.1 as a copy of /usr/src/linux-2.6.18 and applied the 2.6.18.1 patches to the new directory tree. It would seem (in view of the above problems) that this may not be the ideal way to do it. I've now changed names so that I have /usr/src/linux-2.6.18.base (as the original version) and /usr/src/linux-2.6.18 which is the patched version but then it's a bit more difficult to keep track of which version you patched to.
Generally, I jump on the kernel upgrade bandwagon sometime after the primary version release and download a full tarball of the required version. As an example, my main kernel is a 2.6.17.7, although I am monitoring the 2.6.18 cycle.. Even after downloading the full tarball, I end up patching with a third party patch set, so on occasion have to deal with rejected hunks... The last time I had to deal with an incremental 2.6.xx.x kernel patch, it had to be applied to a virgin primary release. This would mean that you would need a clean, unpatched 2.6.18 tree to start from - There is little need to keep a complete tree on the build system as long as you retain the original tarball..
Once untarred and patched, the first thing to do is to check the EXTRAVERSION variable at the top of the kernel's Makefile. If you want to add an additional identifier, use the LOCALVERSION option during the config stage (and check the .config afterwards)..
As to how I track which version and source currently installed - Compiling in /usr/src/linux-yadda is deprecated in favour of a "where ever you want" policy, so I will sometimes use /tmp/linux, and always with make-kpkg. The /tmp directory gets cleaned out on each reboot, but make-kpkg will produce a set of easy to install Debian packages which will get ferreted away in a local repository..
With regards your problem compiling an RTL8168 driver... After downloading the sources direct from Realtek, it would appear that they need "adjustments" before you can compile against a 2.6.18.x kernel - MODULE_PARM has been dropped and needs to be replaced module_param_array (see http://www.atworkonline.it/~bibe/etch/index.htm for details).. You should be able to override the kernel version by passing it as a make option, e.g. `make KVER=2.6.18.1-foo`, failing that, edit the make file..
What's vmware ? <ducks>
Regards, Paul.