* Halil Pasic (pa...@linux.vnet.ibm.com) wrote: > > > On 06/07/2017 01:07 PM, Dr. David Alan Gilbert wrote: > > * Halil Pasic (pa...@linux.vnet.ibm.com) 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 <pa...@linux.vnet.ibm.com> > > > > 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?
Disagree. I don't mind giving field names etc; they make it easy for us as developers to track down what's happening, but also sometimes they help endusers work around a prolem or see where the problem is; of course that varies depending on the field name, but some of our names are reasonable (e.g. there's a VMSTATE_INT32_EQUAL on 'queue_size' in vmmouse.c). They're also pretty good if two end users hit the same problem they can see the same error message in a bug report. We often have customer-facing support people look at logs before they get as far as us developers; if we have bugs that are 'if it's a failing BLAH device complaining about the BAR field' then this fixes it, then that helps them find workarounds/fixes quickly even if they don't understand what the BAR field is. > > > > > (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? Yes, that would be a lot simpler; and there aren't that many VMSTATE*EQUAL* macros in use. Dave > Regards, > Halil > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK