[libvirt] [PATCH 08/19] storage: Use consistent variable names for driver
John Ferlan
jferlan at redhat.com
Sun Jul 16 15:48:43 UTC 2017
On 07/14/2017 09:53 AM, Pavel Hrdina wrote:
> On Tue, May 09, 2017 at 11:30:15AM -0400, John Ferlan wrote:
>> A virStoragePoolObjPtr will be an 'obj'.
>
> Now that I'm thinking about it, this should be poolObj or poolobj, it
> would make it easier using git grep and also some functions takes more
> than one object. We should thought about it earlier, some of these
> patches are already pushed.
Consistently speaking for any of the drivers (nodedev, nwfilter, secret,
interface, network, pool, volume, and domain) - I've been going with
@obj whenever possible, but I do see value in @poolobj, @nodedevobj,
@nwfilterobj, @secretobj, @interfaceobj, @networkobj, @vol[ume]obj, and
@domainobj. But going through another round of changes to just change
the name isn't something I'd look forward to.
If you think back to my original series - everything was a @poolobj
because my object was a PoolObj.
Still to me an @obj within the specific driver/vir*obj.c source is the
same. When there's more than one type of @obj, then @obj would be for
the primary object while @XXXobj would be for the secondary object. Thus
for storage pools an obj is a poolobj. Using git grep or cscope to find
@obj and filtering further via the "src/storage" or "src/nodedevice",
etc. shouldn't be that difficult. The caveat to all that is the storage
pools also have volume objs, which I think you point out in the follow
up I needed to be more consistent about. The general way I had those
was @volobj.
John
>
> Let's discuss it before pushing more of these patches.
>
> The rest is OK.
>
>> A virStoragePoolPtr will be a 'pool'.
>>
>> A virStorageVolPtr will be a 'vol'.
>>
>> A virStorageVolDefPtr will be a 'voldef'.
>>
>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>> ---
>> src/storage/storage_driver.c | 1158 +++++++++++++++++++++---------------------
>> src/storage/storage_driver.h | 4 +-
>> 2 files changed, 582 insertions(+), 580 deletions(-)
>
> Pavel
>
More information about the libvir-list
mailing list