[libvirt] [PATCH v2 06/14] qemu: Introduce privateData for _virStorageSource

John Ferlan jferlan at redhat.com
Fri Sep 22 15:12:05 UTC 2017



On 09/21/2017 10:31 AM, Peter Krempa wrote:
> On Fri, Sep 15, 2017 at 20:30:09 -0400, John Ferlan wrote:
>> Since the secret information is really _virStorageSource specific
>> piece of data, let's create a privateData object for _virStorageSource
>> and move the @secinfo from _qemuDomainDiskPrivate into a new
>> _qemuDomainDiskSrcPrivate structure and manage it from there.
> 
> This would be easier to review if you'd split the private data addition
> and the movement of the auth data to it.
> 
>>
>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>> ---
>>  src/conf/domain_conf.c    |  5 +++++
>>  src/conf/domain_conf.h    |  1 +
>>  src/qemu/qemu_command.c   |  6 ++++--
>>  src/qemu/qemu_domain.c    | 54 +++++++++++++++++++++++++++++++++++++++++------
>>  src/qemu/qemu_domain.h    | 17 +++++++++++----
>>  src/qemu/qemu_hotplug.c   | 11 +++++++---
>>  src/util/virstoragefile.c |  1 +
>>  src/util/virstoragefile.h |  3 +++
>>  8 files changed, 83 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
>> index 542d14ed6..a3900488f 100644
>> --- a/src/conf/domain_conf.c
>> +++ b/src/conf/domain_conf.c
>> @@ -1720,6 +1720,11 @@ virDomainDiskDefNew(virDomainXMLOptionPtr xmlopt)
>>          !(ret->privateData = xmlopt->privateData.diskNew()))
>>          goto error;
>>  
>> +    if (xmlopt &&
>> +        xmlopt->privateData.diskSrcNew &&
>> +        !(ret->src->privateData = xmlopt->privateData.diskSrcNew()))
>> +        goto error;
> 
> This certainly is not enough. The virStorageSource structure needs to
> allocate it in it's helper. This will only fix the top level one and not
> the nested/chained ones for the backing store.
> 

Just so it's clear what you're asking...

Create virStorageSourceNew or virDomainDiskSourceDefNew?

Going with virStorageSourceNew would seem more correct; however, then it
should live in virstoragefile.c and thus wouldn't be able to use the
domain_conf infrastructure.  Seems like it's own infrastructure would
need to be build. It would work with the virStorageSourceNewFromBacking*
which I believe you are referencing.

Going with virDomainDiskSourceDefNew would follow the other models and
be able to live in domain_conf making it easy for the domain_conf
privateData manipulation code, but it just doesn't feel right.

John

>> +
>>      return ret;
>>  
>>   error:
> 
> 
> Rest looks okay.
> 




More information about the libvir-list mailing list