On Tue, Dec 19, 2006 at 06:48:16PM +0000, Daniel P. Berrange wrote:
The code for managing config files in /etc/xen assumed that the
filename of
the config matched the name of the guest defined inside. One might thing
this a reasonable assumption, but in the wild I've had reports from users
whom have various config files for the same guest, but with different
settings. This caused some really wierd behaviour in the current code base.
virt-manager display would alternate displaying each config upon refresh!
Now, our API requires that there is only one config per name, so we can't
expose this to the UI. The attached patch, thus simply detects when we
have more than one config with same named guest, and hides the duplicates.
The way it does this is to change the way we cache configs. Previously we
had a single hash table mapping relative filenames to virConfPtr objects,
with the implicit assumption that relative filename == guest name. With
the attached patch we now maintain two hash tables. The first maps fully
qualified pathnames to virConfPtr objects, the second maps guest names
to the first filename found for that name. Thus when querying details for
a guest, we first resolve the guest name to its filename, and then lookup
the virConfPtr object associated with this filename.
This isn't perfect, but its a hell of alot better than current code, so
I want to commit it as is and figure out more improvement later. There is
no ABI issue here, so we can iterate over impl at will.
okay sounds fine to me...
+ value = malloc(sizeof(virConfValue));
+ value->str = strdup(filename);
+ free(value);
+ return (-1);
This makes me think about an idea I had to swicth all allocations in
libvirt to reuse xmlMalloc/xmlFree/xmlStrdup . The reasons are the following:
- libxml2 is a mandatory module
- libxml2 memory debug allow to track easilly memory allocations
and check we never leak, this can be really useful
- libxml2 memory routines can also be overiden by the library client
to use a different allocator which in some circumstances can be really
useful
My prime motivation is debug but reuse of libxml2 facilities is not neglectible.
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/