[libvirt] [PATCH 7/8] qemu: Support newer ivshmem device variants

[Martin Kletzander]

On Fri, Oct 14, 2016 at 10:19:58AM -0400, John Ferlan wrote:
>[...]
>
>>>> +char *
>>>> +qemuBuildShmemDevStr(virDomainDefPtr def,
>>>> +                     virDomainShmemDefPtr shmem,
>>>> +                     virQEMUCapsPtr qemuCaps)
>>>> +{
>>>> +    virBuffer buf = VIR_BUFFER_INITIALIZER;
>>>> +
>>>> +    virBufferAsprintf(&buf, "%s",
>>>> virDomainShmemModelTypeToString(shmem->model));
>>>> +    virBufferAsprintf(&buf, ",id=%s", shmem->info.alias);
>>>> +
>>>> +    if (shmem->server.enabled)
>>>> +        virBufferAsprintf(&buf, ",chardev=char%s", shmem->info.alias);
>>>> +    else
>>>> +        virBufferAsprintf(&buf, ",memdev=shmmem-%s",
>>>> shmem->info.alias);
>>>> +
>>>> +    if (shmem->msi.vectors)
>>>> +        virBufferAsprintf(&buf, ",vectors=%u", shmem->msi.vectors);
>>>> +    if (shmem->msi.ioeventfd) {
>>>> +        virBufferAsprintf(&buf, ",ioeventfd=%s",
>>>> +
>>>> virTristateSwitchTypeToString(shmem->msi.ioeventfd));
>>>> +    }
>>>> +
>>>> +    if (qemuBuildDeviceAddressStr(&buf, def, &shmem->info, qemuCaps)
>>>> < 0) {
>>>> +        virBufferFreeAndReset(&buf);
>>>> +        return NULL;
>>>> +    }
>>>> +
>>>> +    if (virBufferCheckError(&buf) < 0)
>>>
>>> Still would need to FreeAndReset - I'd be OK if it were an || to the
>>> previous if, although I know that causes agita for others.
>>>
>>
>> Well, not really.  The content gets free()'d whenever the buf->error is
>> set, so it is already cleared if there was an error.
>>
>
>That's not how I read/see other callers of virBufferCheckError and I see
>no free in virBufferCheckErrorInternal
>

It's free()'d when it is *set*, see virBufferSetError (the only place in
virbuffer.c that sets the ->error member).

>
>John
>
>[...]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161014/9b43342c/attachment-0001.sig>