From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nujba-00007t-Vu for qemu-devel@nongnu.org; Thu, 25 Mar 2010 05:43:59 -0400 Received: from [140.186.70.92] (port=55006 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NujbZ-00005Z-7U for qemu-devel@nongnu.org; Thu, 25 Mar 2010 05:43:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NujbX-00025w-CF for qemu-devel@nongnu.org; Thu, 25 Mar 2010 05:43:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31068) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NujbX-00025h-50 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 05:43:55 -0400 Message-ID: <4BAB3054.9030708@redhat.com> Date: Thu, 25 Mar 2010 10:43:48 +0100 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KVM call agenda for Mar 23 References: <20100323061140.GN29498@x200.localdomain> <4BA88A6F.2050703@web.de> <4BA88F5D.6040008@redhat.com> <4BA8B7FB.2050103@codemonkey.ws> <4BA8BA84.3020908@redhat.com> <4BAB2F6B.5010400@web.de> In-Reply-To: <4BAB2F6B.5010400@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Chris Wright , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , Avi Kivity On 03/25/10 10:39, Jan Kiszka wrote: > Zhang, Xiantao wrote: >> For ia64 part, maybe we can keep the current qemu-kvm.git for the users. And it is not a must to push it into Qemu upstream. >> Xiantao >> > > Does it still build& work? Does someone test it at least infrequently? > Or are there users? > > There were a few changes recently due to cleanups and/or switches to > upstream code. There will be more in the future. And at some point heavy > work will be needed when there are no more qemu-kvm* files. That could > be a point ia64 breaks forever unless someone jumps in. > > BTW, I'm also carrying ia64 bits in kvm-kmod. I never compiled them > (except for the "make headers_install" which throws tons of warnings at > me), I'm just keeping them for now to enforce architecture separation in > case someone once wishes to add another arch to this wrapper. I think the end result will be that an older version of qemu-kvm will be around, and if someone decides to pick up on it, they will have to work from that. At this point I only see some of the Japanese vendors potentially being interested, but I think they have mostly been looking at Xen/ia64. Then again, I have no idea what the state is for Xen/ia64 patches for QEMU, in theory a lot of it should be shared. As long as the bits are sitting in the tree without disturbing other parts, then I just think we should let them sit there. Cheers, Jes