Arnd Bergmann wrote: > On Thursday 10 December 2009, Avi Kivity wrote: >> Maybe even /usr/local/include/kvm-kmod-$version/...., and a symlink >> /usr/local/include/kvm-kmod. > > Depends on how fine-grained you want to do the packaging. > Most distributions split packages between code and development > packages. The kvm-kmod code is the kernel module, so you want > to be able to install it for multiple kernels simultaneously. > > Building the package only requires one version of the header > and does not depend on the underlying kernel version, only > on the version of the module, so it's reasonable to install only > one version as the -dev package, and have a dependency > in there to match the module version with the header version. > > The most complex setup would split the development package > into one per kernel version and/or module version, plus an > extra package for the module version containing only the > symlink. I wouldn't go there. I've just (forced-)pushed the "simple" version with /usr/include/kvm-kmod as destination. The user headers are now stored under usr/include in the kvm-kmod sources and installed from there. > >>> It may also be useful to do the equivalent of 'make headers_install' >>> from the kernel, to remove all "#ifdef __KERNEL__" sections and >>> sparse annotations from the header files, but it should also work >>> without that. >>> >> Well, qemu.git needs __user removed. > > This one is taken care of by kvm_kmod in the sync script, though it > would be cleaner to only do it for the installed version of the header, > not for the one used to build kvm.ko. It's easy to drop, but I wonder why it was introduced. To allow reusing the headers for user space? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
