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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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,
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