On 03/18/2017 01:49 PM, Laine Stump wrote: > On 03/18/2017 09:26 AM, John Ferlan wrote: >> In an effort to be consistent with the source module, alter the function >> prototypes to follow the similar style of source with the "type" on one >> line followed by the function name and arguments on subsequent lines with >> with argument getting it's own line. >> >> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> >> --- >> src/conf/network_conf.h | 84 ++++++++++++------- >> src/conf/virnetworkobj.h | 212 ++++++++++++++++++++++++++++------------------- >> 2 files changed, 182 insertions(+), 114 deletions(-) > > You've made this change for several files now. I always thought it would > be simpler to have the return type on a separate line to match the .c > file, but since all the .h files have it on the same line, I've been > dutifully adjusting the alignment of all the new prototypes I add. Yeah - me too - that's what I've done up to this point in time... > > So is this a "thing" now? Should I add new prototypes with the return > type on a separate line? > That's what I was asked to do by Pavel quite a few patches ago for anything new I created. Since I was touching one thing I figured I'd just do it for the other to be "more complete" (it's mundane and to a degree I don't see the point beyond keeping things the same in all our code). Perhaps it's one of those Type A things to do ;-) > As always my one objection would be that these large patches to reformat > things mostly just obscure the history of the most recent "real" change, > and create annoying (but usually easily resolvable) merge errors when > backporting future fixes to previous versions. > Understood - been there before chasing history - that's when I really came to enjoy the wonders of gitk. Separating out the "object" and "XML" parse/format API's is a really boring, rote exercise, but hopefully reduces future merge conflicts. The next step in the process is to make all those vir*Obj[List] structs become more object like. My first pass was deemed way too confusing, thus the need to take smaller steps. In the end a virNetworkObj would take say a virObjectPoolable rather than Lockable, where the Poolable object would store all the common fields between various drivers and would have common methods to fetch, store, search, etc. That'll make things even harder to backport, but the upside is Hash Tables (the intended mechanism) are way faster than forward linked list searches. The other benefit is that as a writer of a driver module you don't have to essentially cut-n-paste some other drivers list mgmt functions - you'd just use the object API's (at least that's the plan!) John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
