Re: [libvirt] [PATCH v2 2/3] qemu: Implement virDomainGetDiskErrors

On 01/30/2012 09:01 AM, Jiri Denemark wrote: Ah, so this only returns disks with errors. Document that in the public API. Do we really want to error out if we can't tell them about _all_ known errors? Let's think back to my request in 1/3 - if the user can query how many errors are present, and at the moment we answer the query, there is only 1 disk with an error, but before they can allocate and repeat the request, we encounter a second error. Either they should _always_ pass us space for _all_ disks tied to the domain (and fail if nerrors < vm->def->ndisks), or we should allow for races with the user passing in a too-small array, where we just give back as much information as they gave us room for, rather than erroring out because they didn't give us enough room. In fact, if you go with my request to allow the user shorthand, I'm okay with special case nerrors == 0 to just blindly return vm->def->ndisks, even if there aren't that many errors, so that the user will be unlikely to ever pass us too small of an array (the user should be prepared for the return value to be less than maxerrors on input, in fact, a return value of 0 when there are no errors would be reasonable in the case where the array is non-NULL). The virTypedParameter cases must not reject a too-small array, but then again, that is for back-compat reasons (it is likely that a newer server introduces attributes not expected by an older client, so if the older client hard-coded the array size, the newer server should still deliver only the older stats that the older client was expecting); but for the disk error case, the number of disks is dependent on how many disks are attached to the domain, and not something where newer servers will see more disks than older clients, so for this API, I can live with an error if the user's incoming array is too small. Do we still need to implement this in qemu_monitor_text, now that we require JSON for any qemu version new enough to actually provide this information in the first place? -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org