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