On 12/21/2010 11:34 AM, Chris Lalancette wrote:
All,
I'll preface this by saying that I'm not 100% sure I'm correct. But I
still think there may be an API break that was introduced with the VMware
player driver. In include/libvirt/virterror.h, VIR_FROM_VMWARE was added to
the *middle* of the enum for virErrorDomain. If any clients of libvirt happen
to be using hardcoded numbers, then they will now have the wrong number for
everything after VIR_FROM_VMWARE.
virterror.h is public, we should fix it now before the next release,
because these values are passed over the wire in RPC calls, and if the
server on one machine uses different values than the client on another
machine, then the client can misinterpret the error values.
Looking back through the history of virErrorDomain, it doesn't
seem like this
is the first time this has happened. What's the thinking with virErrorDomain?
I just glanced at recent changes; we broke virErrorNumber in March 2010
with commit 46e9b0f, but the last time we broke virErrorDomain was
commit f163895 in Mar 2008. (Most other commits that touched mid-enum
were just fixing typos or spacing).
I don't know what to do about those two API breakages.
Part of the API, or up to the clients to properly use the named
enums?
Part of the API, I'm afraid. See the tail end of:
https://www.redhat.com/archives/libvir-list/2010-December/msg00617.html
+/* NB. Fields "code", "domain" and "level" are really
enums. The
+ * numeric value should remain compatible between libvirt and
+ * libvirtd. This means, no changing or reordering the enums as
+ * defined in <virterror.h> (but we don't do that anyway, for separate
+ * ABI reasons).
+ */
+struct virNetMessageError {
+ int code;
+ int domain;
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org