[libvirt] [PATCH v2 07/20] network: Alter virNetworkObj @class_id to be @classIdMap

Michal Privoznik mprivozn at redhat.com
Wed Aug 16 07:36:39 UTC 2017


On 08/16/2017 03:09 AM, John Ferlan wrote:
> 
> 
> On 08/15/2017 11:32 AM, Michal Privoznik wrote:
>> On 07/26/2017 05:05 PM, John Ferlan wrote:
>>> Change the variable name to be a bit more descriptive and less confusing
>>> when used with the data.network.actual->class_id.
>>>
>>> Signed-off-by: John Ferlan <jferlan at redhat.com>
>>> ---
>>>  src/conf/virnetworkobj.c    | 39 ++++++++++++++++++++-------------------
>>>  src/conf/virnetworkobj.h    |  2 +-
>>>  src/network/bridge_driver.c | 10 +++++-----
>>>  3 files changed, 26 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/src/conf/virnetworkobj.c b/src/conf/virnetworkobj.c
>>> index 533ed26..fb533b9 100644
>>> --- a/src/conf/virnetworkobj.c
>>> +++ b/src/conf/virnetworkobj.c
>>> @@ -79,13 +79,13 @@ virNetworkObjNew(void)
>>>      if (!(net = virObjectLockableNew(virNetworkObjClass)))
>>>          return NULL;
>>>  
>>> -    if (!(net->class_id = virBitmapNew(CLASS_ID_BITMAP_SIZE)))
>>> +    if (!(net->classIdMap = virBitmapNew(CLASS_ID_BITMAP_SIZE)))
>>>          goto error;
>>
>> One thing I just realized: This creates a bitmap capable of holding
>> 1<<16 bits - IOW it allocates 8KB of ram even though in reality just the
>> first 10-20 bits are going to be used. Back in the day when I was
>> implementing this there were no self-inflating bitmaps, but I guess we
>> do have them now, right? Maybe we can rewrite this (ofc after you merge
>> these to avoid conflicts) so that the new bitmap is used?
>>
>> Michal
>>
> 
> I never gave it a second thought ;-) I haven't really dug into the
> bitmap code, but I see virBitmapExpand, virBitmapSetBitExpand, and
> virBitmapClearBitExpand that would seem to be useful for someone willing
> to make that kind of alteration.

Right. I'll start working on the patches and probably post them too.

Michal




More information about the libvir-list mailing list