[...]
>>> virCommandPtr cmd,
>>> virQEMUCapsPtr qemuCaps,
>>> int *tpmfd,
>>> - int *cancelfd)
>>> + int *cancelfd,
>>> + char **chardev)
>>> {
>>> - const virDomainTPMDef *tpm = def->tpm;
>>> + virDomainTPMDef *tpm = def->tpm;
>> Don't lose the "const"
>>
>>> virBuffer buf = VIR_BUFFER_INITIALIZER;
>>> - const char *type = virDomainTPMBackendTypeToString(tpm->type);
>>> + const char *type = NULL;
>>> char *cancel_path = NULL, *devset = NULL;
>>> const char *tpmdev;
>>> *tpmfd = -1;
>>> *cancelfd = -1;
>>> + switch (tpm->type) {
>>> + case VIR_DOMAIN_TPM_TYPE_PASSTHROUGH:
>>> + case VIR_DOMAIN_TPM_TYPE_EMULATOR:
>>> + type = virDomainTPMBackendTypeToString(tpm->type);
>>> + break;
>>> + case VIR_DOMAIN_TPM_TYPE_LAST:
>> default:
>> virReportEnumRangeError(virDomainTPMBackendType, tpm->type);
>>
>> We need some sort of error message otherwise we get failed for some
>> reason which is never fun to diagnose.
>
> All other cases I see use the same function without error message. Not
> sure what you mean. We seem to follow a pattern with this now.
>
yeah this is one of those "inconsistent" things we have. It's probably
just reflex action to see a place that returns -1 without an error
message and say - we need one here; however, since the ->type would
already have been validated, not necessary then.
There are some of these switches where the EnumRange is given - so well
it's just habit for me.
John
[...]
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
