On 06/29/2017 10:28 AM, Erik Skultety wrote:
On Thu, Jun 29, 2017 at 09:57:09AM -0400, John Ferlan wrote:
On 06/29/2017 08:12 AM, Erik Skultety wrote:
On Sat, Jun 03, 2017 at 09:11:51AM -0400, John Ferlan wrote:
Rather than passing the object to be removed by reference, pass by value and then let the caller decide whether or not the object should be free'd. This function should just handle the remove of the object from the list for which it was placed during virNodeDeviceObjAssignDef.
One caller in node_device_hal would fail to go through the dev_create path since the @dev would have been NULL after returning from the Remove API.
This is the main motivation for the patch I presume - in which case, I'm wondering why do we actually have to remove the device from the list when handling 'change'/'update' for hal instead of just replacing the ->def with a new instance but it's perfectly fine to do that for udev...I don't see the point in doing what we currently do for hal.
[...]
The main motivation is that in the previous review pass there was a "dislike" of passing the pointer to a pointer for something else I changed, see:
https://www.redhat.com/archives/libvir-list/2017-May/msg01074.html
Also the initial pass at altering this function was questioned, see:
https://www.redhat.com/archives/libvir-list/2017-May/msg01001.html
Well, that comment is true, but the commit message of this patch says that it drops the requirement of passing by reference, thus leaving the responsibility to free the obj to the caller. Now, the way I see it what we should aim at achieving here is reference counted objects, so the vir*ObjFree in the caller would become and *Unref. Therefore IMHO it's not the best approach to introduce another boolean for HAL and leave the vir*ObjFree in the Remove routine, you wouldn't be clearing the object for the caller anyway, so I don't think that is the way to go.
I actually think the better course of action is to be more like the other functions. I believe virNodeDeviceObjRemove should do the virNodeDeviceObjFree for the simple reason that *ObjAssignDef does the alloc and list insertion and *Remove is the antecedent doing the list removal and free. I will adjust the commit message and can even add comments prior to the function (if desired; however, it'll eventually be just a wrapper to a more generic object function). Also, light has dawned over marble head and for hal's dev_refresh the logic will then work correctly anyway since &dev wouldn't be set to NULL. The code doesn't reference data in @dev. All that is important is that @dev was found and removed. Still adding a bool rediscover just makes it more obvious for the next poor soul tripping across this code. If you search through history, you'll find that commit '611480747' introduced this hal dev_refresh anomaly in order to fix a problem in testNodeDeviceDestroy that @obj would not be present. Instead of setting obj = NULL; after calls, the usage of &dev was introduced. I'm undoing that and taking the other approach to set the removed @dev = NULL; (all that during a freeze, too!). See the quagmire this convergence creates ;-) Anyway, I've attached a patch that should be able to be git am'd on top of this one. It will cause merge conflicts in the rest of the series... John
So I took the approach that this code could/should follow other API's. I used cscope and found other similar functions via "vir.*Obj.*Remove" on the "Find this global definition:" - that led me to 7 functions.
I went for basically every module equivalent of this. So the unnecessary lock dance just to compare pointers could be a fairly straightforward follow-up patch across multiple modules if they're consistent.
Of those Interface, NWFilter, and StoragePool each used this forward linked list in a similar manner - so that's what I changed this model to be. As an aside, nwfilterDefineXML can call virNWFilterObjListRemove,
I won't comment on NWFilter as I'm not familiar with it at all.
In hindsight, perhaps I should have solved this by setting a boolean to force calling dev_create(udi) rather than having/forcing each caller to handle calling virNodeDeviceObjFree.
See my comment above, I think that would be a step back in what we're trying to achieve here (comparing it also with other OO languages' practice in this aspect).
/* Simply "rediscover" device -- incrementally handling changes * to sub-capabilities (like net.80203) is nasty ... so avoid it. */ - virNodeDeviceObjRemove(&driver->devs, &dev); + virNodeDeviceObjRemove(&driver->devs, dev);
I guess now that freeing '@dev' is caller's responsibility, you want to free it on function exit after you checked that you actually want to recreate the device - I already expressed my opinion about this above.
I'd like to ignore or get rid of the hal code ;-)
Who wouldn't, honestly...
I think (now) the better option would be to have virNodeDeviceObjRemove make the virNodeDeviceObjFree call as well and have this one caller just know that it ran through this code path in order to force calling dev_create() after releasing the node device lock.
Does that seem like a better option?
From my perspective, not really (but I might be wrong of course, wouldn't be the first nor the last time).
ACK with @dev also freed in hal backend. I'd also like to hear your opinion on calling *AssignDef directly from hal's dev_refresh rather than first removing the device from the list completely.
Erik
I suppose that's possible, but the comment above the call to virNodeDeviceObjRemove similar scares the sh*t out of me ;-)
It just needs a bit of love....and a bunch of cups of coffee ;)...and a platform to test.
Erik