[Top][All Lists]

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

Re: [Qemu-devel] Adding errno to QMP errors

From: Kevin Wolf
Subject: Re: [Qemu-devel] Adding errno to QMP errors
Date: Tue, 19 Jun 2012 11:31:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

Am 19.06.2012 11:20, schrieb Daniel P. Berrange:
> On Tue, Jun 19, 2012 at 09:39:34AM +0200, Kevin Wolf wrote:
>> Am 18.06.2012 20:31, schrieb Anthony Liguori:
>>> Irrespective of anything else, I think it's safe to say the experiment of 
>>> "rich 
>>> errors" has been a failure.  We still have way too many places using 
>>> error_report.
>>> As I mentioned in another thread, I think we should:
>>> 1) Introduce a GENERIC_ERROR QError type.  It could have a 'domain' and a 
>>> 'msg' 
>>> field.
>>> 2) Focus on converting users of error_report over to use propagated Error 
>>> objects.
>>> We shouldn't/can't change existing QError users.  We also shouldn't 
>>> consider 
>>> changing the wire protocol.  But for new error users, we should/can relax 
>>> the 
>>> reported errors.
>>> We need a clear support policy on whether the contents of 'msg' are stable 
>>> or 
>>> not too.
>> Another point that you used to bring up in earlier discussions is
>> translated error messages. If we start returning error messages that are
>> meant to displayed to the user, should we get your gettext patches
>> applied which you did for the GTK backend? libvirt would then have to
>> pay attention to start qemu with the same locale as the client has.
> You can't really start the VM in the same locale as the client app,
> because there's no persistent 1:N relationship between libvirt clients
> and VMs - it is M:N, so you can't choose a single VM. In addition there
> is a bunch of work that libvirt does against VMs in contexts that have
> no associated client. You just have to have 1 system wide locale for
> all QEMU VMs on a host and libvirt.

Good point. So if we ever needed it, we would have to introduce a
monitor command to switch. But in most cases client and server locale
should be the same anyway, so I think we can ignore that part for the start.


reply via email to

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