qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH 2/3] vmstate: error hint for failed equal ch


From: Halil Pasic
Subject: Re: [Qemu-devel] [RFC PATCH 2/3] vmstate: error hint for failed equal checks part 2
Date: Wed, 7 Jun 2017 13:30:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0


On 06/07/2017 01:07 PM, Dr. David Alan Gilbert wrote:
> * Halil Pasic (address@hidden) wrote:
>> Verbose error reporting for the _EQUAL family. Modify the standard _EQUAL
>> so the hint states the assertion probably failed due to a bug. Introduce
>> _EQUAL_HINT for specifying a context specific hint.
>>
>> Signed-off-by: Halil Pasic <address@hidden>
> 
> I'd prefer not to print 'Bug!?' by default - they already get the
> message telling them something didn't match and the migration fails.
> There are none-bug ways of this happening, e.g. a user starting a VM on
> the source and destination with different configs.

I admit, my objective with 'Bug!?' was to provoke. My train of thought is
to encourage the programmer to think about and document the circumstances
under which such an assertion is supposed to fail (and against which it
is supposed to guard).

I do not know how skillful are our users but a 4 != 5 then maybe a name
of a vmstate field is probably quite scary and not very revealing. I doubt
a non qemu developer can use it for something else that reporting a bug.

Consequently if there are non-bug ways one can use the hint and state them.
Your example with the misconfigured target, by the way, is IMHO also be due
to a bug of the management software IMHO.

To sum it up: IMHO the message provided by a failing _EQUAL is to ugly
and Qemuspeak to be presented to an user-user in non-bug cases. Agree?
Disagree?

> 
> (I also worry we have a lot f macros for each size;
> EQUAL, EQUAL_V, EQUAL_V_HINT but I don't know of a better answer for
> that)
> 

If we are going to drop the default hint ('Bug?!' or whatever) then
I think we could just add an extra NULL hint to each existing  _EQUAL
usage, re-purpose EQUAL, and forget about introducing new _HINT macros.

What to you think?

Regards,
Halil




reply via email to

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