On 09/09/2014 02:27 AM, Kevin Wolf wrote: >>> >>> What was our conclusion wrt the human-readable strerror() string for >>> debugging? Didn't we want to add that as well? >> >> I can do it on top of this patch. So, just adding a new field for this >> is fine? > > I think so. Perhaps we should give it an 'x-' name to make clear that > it's a debugging help and not supposed to be parsed by management tools. > Or would that be abuse of that namespace?
I think using x- would be okay for the namespace, but am not sure we need to go that far. We already have other fields without x- that are documented as human-readable only; for example, CommandLineParameterInfo has: # @help: #optional human readable text string, not suitable for parsing. or in our events, QUORUM_REPORT_BAD has: # @error: #optional, error message. Only present on failure. This field # contains a human-readable error message. There are no semantics other # than that the block layer reported an error and clients should not # try to interpret the error string. So I'd be fine with something as simple as 'message' or 'error'. > > The alternative solution (or actually we could do both) would be to > store it somewhere in bs and put it into query-block. Enhancing query-block in addition to the event makes sense, if it is easy enough to do. At this point, we are talking about debugging aids, so as long as they are documented appropriately, I won't be too fussy. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
