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@xxxxxxxxxxxxxxxxxx> > > --- > 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list