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.
So,
Acked-by: Ian Jackson <ian.jack...@eu.citrix.com>
It would probably have been better for me to have got to this point
earlier.
Sorry,
Ian.
