Re: [Xen-devel] [PATCH 07/10 V7] libxl: use the API to setup/teardown network buffering [and 1 more messages]

[Hongyang Yang <yanghy@xxxxxxxxxxxxxx>]

On 05/12/2014 09:18 PM, Ian Jackson wrote:
> Shriram Rajagopalan writes ("Re: [Xen-devel] [PATCH 07/10 V7] libxl: use the API to 
> setup/teardown network buffering [and 1 more messages]"):
> > On Wed, May 7, 2014 at 12:42 AM, Hongyang Yang <yanghy@xxxxxxxxxxxxxx> wrote:
> ...
> >      This patchset is based on the current remus implementation
> >      (without netbuffer) witch is integrated into suspend/resume
> >      code, if as you suggested we pick option 1, the whole remus
> >      structure needs refactoring.  we're working on it, may take
> >      quiet a while.
> ...
> > Just to make sure I am on the same page with you folks,
> > Ian, when you talked about the two options (1) & (2), did you mean the
> > entire remus implementation inside libxl or just "this" setup/teardown code
> > base?
> I think it is OK for some of the Remus code to fit into the rest of
> libxl code via method (1) and some via method (2).
>
> But any particular subfunction should do strictly one or the other.  I
> think, overall, (1) is better.  It would be nice to do (1) everywhere.
> But a series can be acceptable even if it contains some (2).
Thanks for the reply, that's more clear and solved my doubts too.

Thanks,
Yang.

> Thanks,
> Ian.
>
> For reference, the (1) and (2) we are referring to are these:
>
> 1. Make the remus part of this be a fully self-contained standard
>     asynchronous callback-based suboperation, like libxl__xswait,
>     libxl__bootloader, et al.
>
>     In this case you should rigorously follow the existing patterns,
>     defining a clear interface between the two parts, providing a
>     callback function set by the caller, etc.
>
> 2. Integrate the remus part into the suspend/resume code in an
>     ad hoc fashion, with extremely clear comments everywhere about the
>     expected interface, and no extraneous moving parts.
>
> I'm sure you know that but I wanted to save future readers, and anyone
> not following this in detail, the effort of chasing it down.
> .
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel