On 04/19/2012 06:10 PM, Laine Stump wrote: > On 04/19/2012 04:21 PM, Eric Blake wrote: >> I almost copied-and-pasted some redundant () into my new code, >> and figured a general cleanup prereq patch would be better instead. >> >> * src/conf/domain_conf.c (virDomainLeaseDefParseXML) >> (virDomainDiskDefParseXML, virDomainFSDefParseXML) >> (virDomainActualNetDefParseXML, virDomainNetDefParseXML) >> (virDomainGraphicsDefParseXML, virDomainVideoAccelDefParseXML) >> (virDomainVideoDefParseXML, virDomainHostdevFind) >> (virDomainControllerInsertPreAlloced, virDomainDefParseXML) >> (virDomainObjParseXML, virDomainCpuSetFormat) >> (virDomainCpuSetParse, virDomainDiskDefFormat) >> (virDomainActualNetDefFormat, virDomainNetDefFormat) >> (virDomainTimerDefFormat, virDomainGraphicsListenDefFormat) >> (virDomainDefFormatInternal, virDomainNetGetActualHostdev) >> (virDomainNetGetActualBandwidth, virDomainGraphicsGetListen): >> Reduce extra (), per coding styles. > > Actually the libvirt coding style given in HACKING doesn't say anything > about superfluous parentheses (not that I can find). Maybe you're > thinking of coreutils, or gnulib? Hmm, then I'll shorten that out of the commit message. > > I have one reservation, though - this is a lot of code churn, which > increases the likelyhood of merge conflicts when backporting anything > from future code to any recently rebased distro packages (unless you > plan to backport this patch prior to any other backports). I guess it > all comes down to whether you think the advantages of cleaner looking > code outweighs potential time spent resolving extra conflicts (of > course, if you think it's unlikely any bugfixes will need to be > backported to any of this code, then that's a non-problem). Yeah, but I ran into this due to a review comment on my block migration patches. Either it will conflict right away (and then this is effectively part of that series for doing a backport), or it won't conflict for me and therefore likely won't conflict for other backport patches, so I'm willing to accept the risk to backporting. I've gone ahead and pushed this. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list