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(a)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