On 10/25/2016 08:48 AM, Pavel Hrdina wrote: > On Mon, Oct 24, 2016 at 06:46:18PM -0400, John Ferlan wrote: >> Rather than remove the frontend first and then the backend, let's swap the >> order. The order of addition is add the chardev backend if EGD being used, >> then add the RNG object. So there's a dependency there. When we remove, >> unplug the backend first, then remove the object would seem to be a more >> logical step. This would then follow similar processing for disk removal >> where dependent objects (secret and encryption) of the drive are removed >> before the drive is removed. > > Nice catch, qemuDomainRemoveChrDevice needs the same fix. > Going through my pencil/paper exercise, I think I was wrong... Too many objects and similar names. During the attach processing we have (up to this point at least) 1. Add TLS Object (if necessary) 2. Attach chardev for EGD Backend (if necessary) -> NB: Could depend on 1 via 'tlsProps' 3. Add frontend object -> NB: Could depend on 2 via 'props' 4. Add device So the corollary then becomes: 1. Detach Device (in DetachRNGDevice) 2. Delete frontend object (in RemoveRNGDevice) 3. Detach chardev for EGD Backend (if necessary) 4. Delete TLS object When the secobj is added later it's added before TLS and removed after TLS. Since the existing code has the above order, this patch I think is dropped... That does effect the next one, but only insomuch as placement of the delete TLS object per the above order. John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list