Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END inference for v2 compatibility

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

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:
> > Andrew Cooper writes ("Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END 
> > inference for v2 compatibility"):
> >> More importantly however, by design, common code can't call
> >> arch-specific code without a restore_ops hook.  Deduping these would
> >> require breaking the restriction which is currently doing a decent job
> >> of keeping x86-isms out of common code.
> > I'm afraid you're going to have to explain that to me at a bit greater
> > length.  The biggest thing that is confusing me about your statement
> > here is that your patch is indeed adding x86-specific code to a common
> > file.  But also I don't understand the comment about restore_ops
> > hooks - do you mean something in restore_callbacks ?
> 
> No.  restore_callbacks are plumbing between libxl-save-helper and libxc.
> 
> restore_ops are internal to the restore code, and come in x86_pv and
> x86_hvm flavours, with ARM existing in some theoretical future.  The
> design of the common save/restore code had deliberate measures put in
> place to make it hard to get arch-specific details slip into common
> code, so porting to different architectures didn't have to start by
> doing a bunch of cleanup.
> 
> 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.

Well, I still don't quite follow but as you point out on irc I haven't
replied for too long.  I don't think I should withhold my ack at this
stage.

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

Thanks,
Ian.