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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/