[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 03/17] tools/migration: Drop IHDR_VERSION constant from libxc and python [and 1 more messages]

Andrew Cooper writes ("Re: [PATCH v2 03/17] tools/migration: Drop IHDR_VERSION 
constant from libxc and python"):
> I presume you mean here 2x send IHDR and 2x receive IHDR, one C and one
> Python in each case.
> I understand what you're suggesting.  I completely disagree with it, as
> it obfuscates the logic and introduces a source of bugs for zero gain.
> The only thing IHDR_VERSION_* usefully gets you is the ability to get
> the defines accidentally wrong, and introduce bugs that way.

Andrew Cooper writes ("Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END 
inference for v2 compatibility"):
> On 05/03/2020 16:24, Ian Jackson wrote:
> > You could handle that with a small bit of code around one of the call
> > sites to adjust the error handling.  (Also, what a mess, but I guess
> > we're here now...)
> ... which is the majority the code you're trying to abstract away.
> tl;dr I could put an #ifdef x86'd static inline in the root common
> header (xc_sr_common.h), but the overall complexity is greater than what
> is presented here.

I still don't agree with you I'm afraid.  I went back through our
messages, and looked at the code again, and I think we are probably
still not communicating well.  However, I thought about how best to
deal with this disagreement.  As the actual author of much of this
code, and certainly the person putting a lot of effort in, you should
get quite a bit of leeway.

I considered taking your branch and showing you what I meant in code
terms.  But ultimately I think this is a waste of our time and I don't
want us to get into a pointless argument.  I don't think these issues
matter enough to be worth the debate.  I don't think there are actual
bugs here - we're talking about matters of style and taste.


Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

It would probably have been better for me to have got to this point




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.