qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: KVM call agenda for July 27


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: KVM call agenda for July 27
Date: Tue, 27 Jul 2010 20:37:03 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1

 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]