23.02.2011 15:58, Jan Kiszka wrote: > On 2011-02-23 12:42, Michael Tokarev wrote: [] >>> - kvm/include (latest kernel headers) *) >> >> This directory is always used (in configure) >> unless -kerneldir is specified - who uses that >> nowadays? I dunno. > > It may not be relevant to distros, provided they manage to keep their > /usr/include/linux stuff in sync with the kernel they ship. But if you > build qemu-kvm for a kernel (or kvm-kmod) that is more recent than your > user space headers, this matters. 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: 1) qemu-kvm userspace actually checks a feature before using it, and omits some code if the feature isn't available. This means tons of #ifdefs, for a very little gain, 2) kernel interface stays backward-compatible, and 3) the headers included in qemu-kvm tarball actually matches the feature set in the userspace part. Using more RECENT kernel headers to build userspace which don't know about the more recent features anyway should result in exactly the same binary, there's no reason to use more recent headers. >>> *) This should really be discussed upstream again: Carry private copy of >>> kvm headers or rely on distro / kvm-kmod to provide required defines, >>> types etc.? I'm more and more in favor of option 1. >> >> Yes indeed, having current defines of all the features >> we actually support is a good idea. That's the key: current features we actually support. If kernel headers (be them embedded into the userspace tarball or already installed on the system or headers from just built kernel.org git tree) define less than that, we either have tons of #ifdefs or just fail at build/configure time telling "use more recent headers". If kernel headers define more than we can understand, we just ignore the rest... > Would you like to propose this upstream in form of a patch series (that > demonstrates its usefulness by dropping tones of #ifdefs)? ..unless I completely missed the point. Which upstream you're talking about -- qemu or kernel? Where the #ifdefs are, what they're for currently are they really needed? Does qemu[-kvm] want to stay compatible with older kernels, or kernel headers? If yes, how old is old? /mjt -- 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