[...]
>>
>> Doh... true - of course I have in mind the end goal which is making
>> this whole process awfully difficult. Going step by step hasn't really
>> helped as much as it should have /-(. Adjustments to later patches will
>> be necessary to either Unref or EndAPI.
>
> I'm sorry, I don't follow. What changes to later patches are we talking about
> exactly? I agree with the original approach you took because IMHO it is the most
> transparent in terms of gradual changes - replacing frees with unrefs or EndAPIs
> for that matter, and it also keeps things consistent.
>
Pay no attention to the old man talking to himself ;-)
I've gone back to the original 1/12 and just added a
virNodeDeviceObjFree within the if (dev) prior to dev_create(udi). Since
it doesn't matter if the node device is unlocked it's a safe place to
put it.
[...]
>>
>> I'm not sure I follow... Like noted previously trying not to disturb the
>> logic here - just applying a different band-aid
>>
>> The purpose of the Remove AIUI is to allow the code to rediscover some
>> device because no one wanted to handle the messy situation of some
>> capability being removed or some property being modified. Instead it was
>> deemed a better option to just Remove the device and allow dev_create
>> reinstantiate.
>
> It's been a long time since 2008 and there wasn't a exhausting description why
> it was a problem back in 2008 - locks maybe?. Commits d48717054c7 and 6244c173b
> don't really relate to what I'm suggesting, do they? You wouldn't mess around
> with locks, so you wouldn't regress with deadlock. I'm still trying to figure
> out what I'm missing here, since you're holding all the necessary locks anyway
> so what could possibly be the benefit of calling remove on the device prior to
> creating-refreshing it next.
>
> Erik
>
I was trying to figure out why you were advocating removing the Find and
Remove and just call dev_create directly.
AIUI, the code is removing the device and allowing dev_create recreate
it because it was easier than deal with def->caps replacement. Sure
maybe that's easier today, but it's been way too long for me to recall
much about hal other than something to do with 2001: A Space Odyssey
("I'm sorry Dave, I'm afraid I can't do that")...
John
v4 will be posted soon
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
