On Mon, Oct 08, 2007 at 02:29:32PM -0500, Anthony Liguori wrote: > > Eventually, KVM will merge with upstream QEMU. In that case, many > people will be using QEMU without the desiring to use KVM. We don't > want to introduce behavior in QEMU that is unmergable with upstream QEMU > b/c that will just cause users more headache when that behavior is > eventually change.
As I mentioned in the patch proposed, I don't expect for this patch to be ever merged upstream (even if a solution like that might be possible for kqemu based emulations as well). It is for the same reason that I considered this approach; which keeps the changes to a minimum and localized to the KVM patches so it can be easily stripped out when it is no longer needed. The alternatives are IMHO more difficult to manage : 1) Have all users of platforms that have no gcc-3.x (currently OpenSUSE and soon enough Debian and derivatives like Ubuntu) with no way to be able to use kvm, unless they can somehow figure out how to compile a gcc-3.x compiler and use that to build kvm or rely on their distributions to do that for them. 2) Add several patches to our qemu (like the ones from Novell) to get it to build with gcc-4.x. Then everyone (including the ones which should be using gcc-3.x instead) start using it and then we are suddenly supporting performance problems, miscompilation bugs, and overall issues in qemu instead of kvm (not including the misreported bugs from users that though they were running kvm when they forgot to load the module) while making a merge with upstream much more difficult. 3) We do nothing, add a warning to the compilation for the users to read at compile time (most of them not aware that they should be using gcc-3.x instead as they are used to see all the other compilation warnings anyway) and then let kvm segfault when they start it without loading the module first. If nothing, a message saying this won't work because you used the wrong compiler, is IMHO better than a plain segfault. Carlo PS. if qemu gets upstream officially a solution to compile with gcc4, I'll be the first one getting that merged and removing this patch. PS2. getting gcc4 to generate valid chunks of "copyable" code as required by qemu's dyngen is not something that would happen accidentally, for a promising alternative look at the GCC 2007 proceedings abstract "Towards GCC as a compiler for multiple VMs", pages 117-130, http://ols2006.108.redhat.com/2007/GCC-Reprints/GCC2007-Proceedings.pdf ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
