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@xxxxxxxxxx> >>> --- >>> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
