23.02.2011 16:45, Jan Kiszka wrote: > On 2011-02-23 14:15, Michael Tokarev wrote: [] >> It only matters if you want to build qemu-kvm for OLDER >> kernel without support of some features which are used by >> the userspace you're building. Provided 3 things: > > It also matters if you are building for a kernel more recent than the > headers you have (wherever they came from). Think of the scenario that > you build a recent customized kernel for you host. Then you also need to > remember running "make header_install" and picking up those headers for > the qemu build.
Um. We're going in circles :) I mean, qemu userspace does not need kernels more recent than it can understand. So there's no need to use external headers instead of using a copy embedded in the tarball - which may be not up-to-date wrt currently running kernel or currently installed headers, but the extra features available there wont be used anyway since that particular qemu userspace does not understand them anyway. The only situation where using kernel headers not provided by qemu itself is when you want to build qemu for older kernel and omit some features and runtime tests. But this is hardly a good goal to support. For the above scenario (installing a custom very recent kernel but forgetting to run `make header_install') to be of any use, you also need qemu userspace that is able to use the new feature in this shiny new kernel. So to sum it up, we've two options (actually 3, but 3rd isn't very interesting): 1) embed "recent enough" (for this version of qemu) kernel headers and always use this copy, or 2) use system headers and always assume all features we actually understand are present in there, and fail if they're not. This can be a configure-time check (it already is, sort of), so configure can tell the user the minimum required version to install. I've no preference for either of the two, first is more convinient and second has less duplicates. (By "qemu" I mean either qemu or qemu-kvm, since the two tries to become the same thing) [] >> Does qemu[-kvm] want to stay compatible with older kernels, >> or kernel headers? If yes, how old is old? > > Our current minimum requirement is the KVM ABI provided by 2.6.29. The > runtime check is detecting this via the existence of certain key > capabilities. The related build-time check takes place during configure, > probing a list of minimally required KVM_CAPs. > > This last check would become obsolete if we always pick the headers from > a qemu-local copy. Furthermore, we could drop "#ifdef KVM_CAP" around > features that are more recent than our kernel baseline. Runtime checking > will still be required, of course. That check is useful to error out and tell user if the minimum requiriment is not satisfied. Keeping lots of ifdefs isn't useful IMHO. So I'd say keep --with-kernelheaders, keep the checks in configure (maybe activate them if --with-kernelheaders is specified), keep local kernel headers which are recent enough, and remove irrelevant #ifdefs around new API. I'm not sure again I understand your statement about removing #ifdefs in the previous email -- now you say you verified that all #ifdefs are needed. They're either needed or can be removed... ;) But that all went quite far away from dropping old cruft from kvm/ subdir - as we found out, there are 2 useful pieces in there, kvm_stat helper and kernel headers, so let's keep them for now and remove the rest. Anyway, that's quite long "discussion" about nearly nothing... :) Thanks! /mjt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
