From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] Planning for the 0.11.0 release Date: Fri, 10 Jul 2009 18:52:19 +0200 Message-ID: <4A5771C3.7050103@siemens.com> References: <4A401A65.3080804@us.ibm.com> <1247128021.22231.1.camel@blaa> <4A55F150.3020803@codemonkey.ws> <87eisp1gx2.fsf@pike.pond.sub.org> <4A5747E4.3030101@us.ibm.com> <4A57586B.9050900@siemens.com> <4A576317.6010000@us.ibm.com> <4A576AF6.6080307@siemens.com> <4A576D49.40809@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Markus Armbruster , Mark McLoughlin , "qemu-devel@nongnu.org" , kvm-devel , Paul Brook To: Anthony Liguori Return-path: Received: from gecko.sbs.de ([194.138.37.40]:24082 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751055AbZGJQzt (ORCPT ); Fri, 10 Jul 2009 12:55:49 -0400 In-Reply-To: <4A576D49.40809@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > Jan Kiszka wrote: >> Ah, thanks. >> >> OK, then I would like to know the status of my -boot patch queue [1] > > I'm stilling waiting for 1/7 and 2/7. Via the link you posted and in my > inbox, I still don't see those. I do see a 1/2 and a 2/2 but those are > bios patches. Did you have a numbering issue or did some patches get > lost in the ether? Something went wrong during transmission, and I missed that. Just sent out those two as well. > >> and >> at least of patch 1..3 of my gdbstub queue [2] (though I'm still waiting >> for the factual proof that patch 4 is unneeded - my last arguments >> remained unanswered). >> > > Paul expressed objection in the past to the debugging model of treating > vcpus as threads vs. treating them as processes. That's nothing those patches changes (it's our current and only debugging model for SMP until gdb provides a complete solution). The recent discussion went around how to deal with some other gdb limitation: debugging targets that run in x86's 16/32 bit mode vs. the target arch being advertised as 64 bit. Existing qemu code doesn't work with existing gdb in this scenario, and the question was how to deal with it until gdb is improved. > I'm not qualified to > appreciate the difference so I'm inclined to side with Paul. Am I > missing something there? I interpreted [1] as that the rest is OK for Paul. Jan [1] http://permalink.gmane.org/gmane.comp.emulators.qemu/46399 -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPJNn-0004dT-0e for qemu-devel@nongnu.org; Fri, 10 Jul 2009 12:55:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPJNh-0004cC-II for qemu-devel@nongnu.org; Fri, 10 Jul 2009 12:55:33 -0400 Received: from [199.232.76.173] (port=60040 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPJNh-0004c9-9v for qemu-devel@nongnu.org; Fri, 10 Jul 2009 12:55:29 -0400 Received: from gecko.sbs.de ([194.138.37.40]:23717) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MPJNg-0006HI-M3 for qemu-devel@nongnu.org; Fri, 10 Jul 2009 12:55:29 -0400 Message-ID: <4A5771C3.7050103@siemens.com> Date: Fri, 10 Jul 2009 18:52:19 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Planning for the 0.11.0 release References: <4A401A65.3080804@us.ibm.com> <1247128021.22231.1.camel@blaa> <4A55F150.3020803@codemonkey.ws> <87eisp1gx2.fsf@pike.pond.sub.org> <4A5747E4.3030101@us.ibm.com> <4A57586B.9050900@siemens.com> <4A576317.6010000@us.ibm.com> <4A576AF6.6080307@siemens.com> <4A576D49.40809@us.ibm.com> In-Reply-To: <4A576D49.40809@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mark McLoughlin , Paul Brook , Markus Armbruster , kvm-devel , "qemu-devel@nongnu.org" Anthony Liguori wrote: > Jan Kiszka wrote: >> Ah, thanks. >> >> OK, then I would like to know the status of my -boot patch queue [1] > > I'm stilling waiting for 1/7 and 2/7. Via the link you posted and in my > inbox, I still don't see those. I do see a 1/2 and a 2/2 but those are > bios patches. Did you have a numbering issue or did some patches get > lost in the ether? Something went wrong during transmission, and I missed that. Just sent out those two as well. > >> and >> at least of patch 1..3 of my gdbstub queue [2] (though I'm still waiting >> for the factual proof that patch 4 is unneeded - my last arguments >> remained unanswered). >> > > Paul expressed objection in the past to the debugging model of treating > vcpus as threads vs. treating them as processes. That's nothing those patches changes (it's our current and only debugging model for SMP until gdb provides a complete solution). The recent discussion went around how to deal with some other gdb limitation: debugging targets that run in x86's 16/32 bit mode vs. the target arch being advertised as 64 bit. Existing qemu code doesn't work with existing gdb in this scenario, and the question was how to deal with it until gdb is improved. > I'm not qualified to > appreciate the difference so I'm inclined to side with Paul. Am I > missing something there? I interpreted [1] as that the rest is OK for Paul. Jan [1] http://permalink.gmane.org/gmane.comp.emulators.qemu/46399 -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux