On 03/07/2016 04:47 PM, John Ferlan wrote:
On 03/07/2016 10:50 AM, Peter Krempa wrote:
> On Wed, Mar 02, 2016 at 13:54:58 -0500, John Ferlan wrote:
>> To support being able to create a hashed secrets list, move the
>> virSecretObj to secret_conf.h so that secret_conf.c can at least find
>> the definition.
>
> I don't think this is necessary. You still can create accessors and have
> the actual implementation of the struct private in the .c file. That way
> it's guaranteed that nobody will touch the fields directly accross the
> source files.
>
Suffice to say there's still more work to do; however, short term I
think it needs to move so I can make some progress. I will have a
followup series that will move _virSecretObj into secret_conf.c.
The goal for this series was to build up the code to support a hashed
secret object while still having that linked list in the driver. Patch
10 was added to this series mainly since it was discussed in danpb's
review of my last set of secret driver changes. Moving the saving of the
config file and secret data file was next on the todo list.
I should note that the existing model has virDomainObj in
src/conf/domain_conf.h and virNetworkObj in src/conf/network_conf.h, so
virSecretObj wouldn't be unique...
Precedence is a strong argument; so make mention of that in the commit
message. I'm personally okay with this patch, but I'll go ahead and
review the rest of the series first before deciding if attempting to use
accessors and keeping the struct private is worth a respin, or whether
to ack this as-is.
I honestly didn't want another 15-20 patch series floating around. Make
some progress, share, get buy in, continue. The question then becomes
does the rest of the series look good?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org