Ryan Harper wrote:
I also wonder what happens if one tries to build on
a machine with kvm built into kernel. Ideally one would get
a clear error message.
kvm-kmod is really designed for those running on pre-kvm distro kernels,
and for those testing newer kvm versions on distro kernels. If you can
compile your own kernel, download kvm.git and run that.
So no way of having kvm-kmod sync in kvm.git bits and still build
against the current running kernel?
We must be miscommunicating, what you describe is kvm-kmod.git's sole
purpose in life.
I wanted to test out 2.6.29-maint kernel modules and in
kvm-userspace/kernel, I could checkout maint/2.6.29 in kvm.git and then
make LINUX= sync. I couldn't quite figure out how to do that with
kvm-kmod since when I do a ./configure --kerneldir -- it's building
modules *for* whatever kernel is at kerneldir rather than just syncing
in the kvm bits from that kerneldir and then building modules against
the running kernel.
'make sync' will copy the kvm bits from the linux-2.6 directory, or
$(LINUX) if you specify that to make.
So:
LINUX= is for the kvm sources (further controlled by whatever branch
is checked out)
--kerneldir= is for the host kernel
The reason I'm digging is that I'm seeing 64-bit migration failing on
maint/2.6.29 kvm modules, but not on upstream kvm kernel bits and I
wanted to bisect to find where 64-bit migration is fixed so I can
suggest what to pull into maint/2.6.29.
Thanks, that's helpful. How does it fail? maybe I can supply an
educated guess.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
