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@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