Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031027 Description of problem: (Note: I know that vmware is neither shipped nor supported by RedHat. Please read on). It seems that one RedHat patch to the current 2.6.0-test9 kernel makes it all but impossible to use vmware on these kernels. Since vmware is a very useful product for a lot of people, I'd be happy if you'd take a look at it. The patch in question is "linux-2.6.0-compile.patch", changing the argument passing to functions. The usenet tread describing the problem can be found at http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&threadm=pan.2003.10.26.05.34.09.229786%40othersdietrying.com&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26selm%3Dpan.2003.10.26.05.34.09.229786%2540othersdietrying.com An analysis can be found in this article (part of the thread mentioned above) http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&selm=bo0js3%24ai6%241%40london.vmware.com Version-Release number of selected component (if applicable): kernel-2.6.0-0.test9.1.67 How reproducible: Always Steps to Reproduce: 1. Try to compile the vmmon driver on 2.6.0-test9 2. 3. Additional info:
The problem really is with vmware; their makefile is broken (for 2.6 kernels). If they used a proper makefile it would JustWork(tm).
I am by no means a kernel hacker, but reading the thread above it seems to me that some of vmware's assembler mumbo-jumbo depends on -mregparm=0. Whether this is a good idea in itself is another question.
any and all such functions in the kernel have to be marked "asmlinkage" anyway; if vmware did that correctly it'd just work.
And what is correct Makefile? I tried: ==== default: (cd /usr/src/linux; make SUBDIRS=$PWD modules) obj-m += vmmon.o clean: rm -f core *.o *.a *.s ==== and it (1) fails in MODPOST phase, saying that I need all modules from stock kernel so MODPOST can turn them from .o to .ko, and (2) does not contain rules for C++ sources. While I can work around missing C++ rules by copying CFLAGS & so on, I have no idea how I can change Makefile to build only vmmon.ko, without building also floppy.ko, rtc.ko, ... Documentation/kbuild/modules.txt says only "The information herein is correct but not copmplete", and "Documentation/kbuild/makefiles.txt" did not point correct solution to me. And what about second half of complaint (which is only on newsgroup, not here yet): There is /boot/vmlinux-2.6.0-0.test9.1.67smp - > /usr/lib/debug/lib/modules/2.6.0-0.test9.1.67/smp/vmlinux symlink in kernel-smp package, but I was not able to find package which contains symlink target so that kernel debugging is really possible...
the documented way is to have a file called makefile with all: make V=1 -C /lib/modules/`uname -r`/build SUBDIRS=$$PWD modules in it and a file called Makefile with obj-m += vmmon.o in it. the vmlinux file is in the kernel-debuginfo package (which isn't available on my people site since it's too big so that I go over my quota and would have to drop the i586 kernels instead)
oh and btw, using /usr/src/linux-* is REALLY not going to work with the 2.6 rpms anymore, the fact that it "worked" with the 2.4 rpms is purely coincidental.
No problem with /usr/src/linux-*, we prefer /lib/modules/... for years, as long as that directory exists. But problem is that 'make ... SUBDIRS=$$PWD modules' does not work reliably: If there is .o file anywhere in source tree, and its .ko is out of date (or does not exist), 'make SUBDIRS=XXX modules' will rebuild not only .ko in SUBDIRS, but all .ko, in whole kernel source tree. You can see that Makefile.modpost is invoked with all modules, not only with modules built in this step. But as this does not happen unless user did something unusual to his tree, I think that I'll have to live with it.
the /build tree doesn't have .c files nor .o files so it can't be out of date.
Feel free to close this bug, pointing people to the http://platan.vc.cvut.cz/ftp/pub/vmware, for vmware-any-any update 44 or later.