[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.



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



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