Gerd Hoffmann wrote:
On 10/30/09 13:28, Luiz Capitulino wrote:
- qemu_error("Device \"%s\" not found. Try -device '?' for
a list.\n",
- driver);
+ qemu_error_structed(QERR_DEV_NFOUND, "{ 'name': %s }",
driver);
why not store the "{ 'name': %s }" in the qerror_table? I guess you
plan to have different fields in some cases?
The main reason is to have syntax checking, we can declare it in a
macro though, in case of generic errors which are going to be used in
other places.
I still feel the error reporting is too complex. IMHO there should be
no need to edit two places for error reporting, which means I'd go the
opposite direction: Zap qerror_table[], then have:
qemu_error_structed(QERR_DEV_NFOUND, "device %{name}s not found",
"{ 'name': %s }", driver);
Also I think the error codes should be more generic, so you don't need
a new one for each and every error. Ideally we'll have a reasonable
and stable set of error codes after the initial conversion, so you
don't have to touch the management apps just to add new codes as qemu
envolves. The error code must help the management app to decide how
to deal with the error, but it shouldn't carry details not needed for
that.
Okay, let's get more clever then and do:
#define QERR_DEV_NFOUND "{ 'code': 404, 'name': %s}"
So we can do:
qemu_error_structured(QERR_DEV_NFOUND, driver);
Such that we still get printf style parameter checking.
Picking the balloon errors (other patch in this thread): You have
*two* error codes for ballooning not being available. I think a
generic "service not available" error code would work for both (and
for other error cases too) and would be good enougth. The management
app will figure it can't balloon down the VM. It will not know the
reason from the error code, but does it have to? I doubt it will
react in a different way. And for manual trouble-shooting the text
message which carries more information gets logged.
I think the trouble is Luiz is trying to preserve today's error
messages. Honestly, if we need to break those, I don't mind so much
because I really doubt anyone is depending on the exact text of the
error messages.
I agree that a bit more generic error messages wouldn't be a bad thing.
--
Regards,
Anthony Liguori
