On 2011-02-23 15:30, Michael Tokarev wrote: > 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. Right. > > 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. I don't think the goal of the #ifdefs was ever some kind of size optimization but just for the sake of avoiding build breakages. > > 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. 2) is no option as the delta between a qemu version and the available headers can easily become too large (e.g. in Debian...). > > 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. That configure check already reduced the size of that forest. Or course, we could also move all inlined #ifdefs to the configure check - if we continue to allow building against different headers than the included ones. But I would prefer to avoid this in order to reduce the variations (of which one combination always break). > > 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... ;) They are needed ATM as we allow building against any headers of >= 2.6.29. They would become obsolete if we provided the right ones in-tree. > > 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... :) Well, "rm -r kvm" is a rather minor thing. But the header discussion is important IMO as we continue to see breakages in KVM builds (mostly qemu upstream) due to missing #ifdefs. That means: - we do not test all variants (because it's impractical) - people use older headers - too much effort is wasted on fixing distributed problems that can be solved centrally 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
