[Libvir] generator.py -- why?

pvetere at redhat.com pvetere at redhat.com
Tue Aug 29 03:53:09 UTC 2006

Hi all.  So, I found a bug in the python bindings that I'd really like to fix,
but when I sat down to do so I quickly found myself mired in a swampy mess of
code generation: generator.py.  :-)  Now, I feel compelled to ask -- why don't
we just have a static libvirt.py file that is WYSIWYG?  The generator.py
program alone is longer than the file it generates, and having a static file
would not only make the code easier to read, but would also make bug fixing
much simpler.  But, I'm sure there's got to be a good reason for it.  :-)

Here's a program that produces the bug I tried to address:

import libvirt
def get_domain(dom_name):
    conn = libvirt.openReadOnly(None)
    domain = conn.lookupByName(dom_name)
    return domain
d = get_domain("mydomain")
print d.info()

This is a fairly typical "factory" pattern I could imagine people using.  The
problem is that the connection object falls out of scope after the get_domain
routine ends, and is therefore garbage collected.  This leaves the "d" domain
object with no valid connection, resulting in a "libvir: Xen error : failed Xen
syscall  ioctl  3166208" error.  The simple solution would be for the connection
object to pass a reference to itself into each domain object it creates.  The
domain objects would then maintain the reference until they are destroyed.

I valiantly tried to follow the table-based patterns used in generator.py to fix
this problem, but I found myself inventing somewhat arbitrary rules just to
force the code I wanted it to output.

And hence, $SUBJECT.  :-)


More information about the libvir-list mailing list