Re: [libvirt] [PATCH 3/5] conf: Alter coding style of network conf function prototypes
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(a)redhat.com>
> ---
> 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