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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/