On 02/04/2013 10:01 AM, Stefan Berger wrote:
Add a growable bitmap implementation building on top of the
'regular'
bitmap implementation. (no doubt, this could also be done differently...)
This patch also adds a test virgbitmaptest.c that is largely a copy of
virbitmaptest.c with some minor modifications to test for growth of the
bitmap.
Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com>
---
PS: This patch builds on top of a patch with a virBitmapNextClearBit
implementation.
In addition to Dan's comments...
virBitmapNextClearBit makes sense to add in isolation (our code should
provide symmetric handling of a bitmap; and the fact that we can iterate
over set bits but not clear bits is a wart worth fixing). However, in
the context of fd passing, I'm not so sure we need a bitmap at all,
growable or otherwise. It should be sufficient just to have a per-vm
single integer set to the highest fdset number allocated so far; any
time a new fdset is needed, we increment the per-vm integer (even if
that leaves gaps in lower-valued fdsets), and on libvirtd reload, the
post-processing pass would merely set the integer to one more than the
maximum fdset seen among all the devices. Thus, I'm a bit worried that
this code is a tangent that will end up not being needed in the fdset case.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org