From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53394 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdoKl-0007U3-Oe for qemu-devel@nongnu.org; Tue, 27 Jul 2010 13:52:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Odo5X-0006OX-Fm for qemu-devel@nongnu.org; Tue, 27 Jul 2010 13:37:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24159) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Odo5X-0006OM-91 for qemu-devel@nongnu.org; Tue, 27 Jul 2010 13:37:11 -0400 Message-ID: <4C4F193F.3080307@redhat.com> Date: Tue, 27 Jul 2010 20:37:03 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KVM call agenda for July 27 References: <4C4ED85B.2090807@codemonkey.ws> <4C4EDEF1.9060507@redhat.com> <4C4EFB04.30901@codemonkey.ws> <4C4F0682.3020400@redhat.com> <20100727162449.GR12387@redhat.com> <20100727162913.GC7474@x200.localdomain> <4C4F0A11.5060204@redhat.com> <20100727163611.GD7474@x200.localdomain> <4C4F0C7A.4030309@redhat.com> <20100727170142.GU12387@redhat.com> In-Reply-To: <20100727170142.GU12387@redhat.com> 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: "Daniel P. Berrange" Cc: Chris Wright , Kevin Wolf , kvm@vger.kernel.org, qemu-devel@nongnu.org, Markus Armbruster On 07/27/2010 08:01 PM, Daniel P. Berrange wrote: > >> It's annoying to us old hands, but it does give that nice integrated >> system feel that we're missing, and it works even if virt-manager is in >> the background (or if you don't use virt-manager at all). >> >> Given that there's a kerneloops pluging that presumably does similar >> parsing, I don't think it's too hard: >> >> $ size /usr/lib64/abrt/libKerneloopsScanner.so >> text data bss dec hex filename >> 18293 1416 16 19725 4d0d >> /usr/lib64/abrt/libKerneloopsScanner.so > One issue though - a kernel oopps is a clear bug. A failure to start > QEMU is often just a mis-configuration, not a bug. We don't want to spa > developers with ABRT reports everytime a user misconfigures a guest. Shouldn't libvirt/virt-manager know that the configuration will fail beforehand? Well, I guess for things like broken paths or bad permissions, no. So we should clearly differentiate between qemu reporting its own bugs (a warn() function) and qemu reporting user errors. In fact that's what the kernel does, ordinary printk()s aren't reported, just bugs. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.