[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.

So,

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

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

Sorry,
Ian.



 


Rackspace

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