Re: [Libvir] Fix handling of config files with duplicate named guests

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.