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