[libvirt] [PATCH 10/10] secret: Move and rename secretLoadAllConfigs

[Cole Robinson]

On 04/19/2016 12:30 PM, John Ferlan wrote:
> 
> 
> On 04/19/2016 11:10 AM, Cole Robinson wrote:
>> On 04/19/2016 08:01 AM, John Ferlan wrote:
>>>
>>>
>>> On 04/18/2016 05:48 PM, Cole Robinson wrote:
>>>> On 03/02/2016 01:55 PM, John Ferlan wrote:
>>>>> Move to secret_conf.c and rename to virSecretLoadAllConfigs. Also includes
>>>>> moving/renaming the supporting virSecretLoad, virSecretLoadValue, and
>>>>> virSecretLoadValidateUUID.
>>>>>
>>>>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>>>>> ---
>>>>>  src/conf/secret_conf.c     | 175 +++++++++++++++++++++++++++++++++++++++++++++
>>>>>  src/conf/secret_conf.h     |   3 +
>>>>>  src/libvirt_private.syms   |   1 +
>>>>>  src/secret/secret_driver.c | 174 +-------------------------------------------
>>>>>  4 files changed, 181 insertions(+), 172 deletions(-)
>>>>
>>>> ACK, mirrors network_conf.c layout.
>>>>
>>>> (though honestly I'd rather we have separate files for XML handling and object
>>>> handling... the existing conf.c files are too large anyways. I put an entry on
>>>> the LibvirtFirstBugs wiki page about that type of code reorg though it's
>>>> probably over an initial contributors head)
>>>>
>>>
>>> I could go the route of a "virsecretobj.c" (to partially mimic the
>>> virdomainobjlist.c) instead of cramming everything into secret_conf -
>>> there's about 1000 new lines in secret_conf just for this series (with
>>> the reduction of lines in secret_driver).
>>>
>>> It would mean a complete v2 of this series - although considering most
>>> things have been ACK'd the second review should be easier. I think
>>> there's only a couple of issues/questions to resolve from reviews.
>>>
>>
>> Oh I wasn't trying to imply making it a requirement of this series. Definitely
>> an additive thing, and I'm not even trying to pin you with the work, just
>> floating the general idea
>>
> 
> Understood - I'd rather do it now than take a hit at some unknown future
> point in time to essentially do the same thing. In the long run it's the
> "right thing" to do.
> 

Yeah but I hate to see self contained changes get held up just to accommodate
an additional cleanup. Reviewer bandwidth is the bottleneck here

- Cole