On Tue, Oct 26, 2010 at 10:36:15AM +0100, Daniel P. Berrange wrote: > On Mon, Oct 25, 2010 at 03:56:58PM -0600, Eric Blake wrote: > > It feels like we're burning through these flag bits rather quickly: 15 > > flags added since January of this year. While it doesn't affect your > > patch, it means that at the current pace we have less than 18 months > > before we have to add a second flag variable. > > This isn't a problem. This is an internal ABI only, so we can change the > way we represent this anytime we like. > > There is a bigger problem in this area. We run 'qemu -help' every time > we do any operation on the guest that requires these flags to be known. > This is bad because the 'qemu' binary may not be the same qemu binary > that we originally booted the guest with (ie RPM package upgrade). We > can thus detect the wrong flags potentially. > > What I think we should do is define a bitset type 'virBitset'. Change > this to a plain enum, instead of a flag based enum, thus giving us > 2^64 entries. We can then have APIs like virBitsetIsSet(num). The > virBitset data should be stored in the virDomainObjPtr instance at > the time of guest booting. We also need to persist it in the XML state > file /var/lib/libvirt/qemu/$guest.xml, as named enum entries, and reload > this at libvirtd restart. > > I'm not likely to have any time to implement this in the forseeable > future though. Hopefully someone can do it before we use up the last > 20 flags :-) Any chance this could end up in http://libvirt.org/todo.html in an "Internals" section ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list