Re: [Xen-devel] [PATCH v2 COLOPre 11/13] tools/libxl: rename remus device to checkpoint device

[Yang Hongyang <yanghy@xxxxxxxxxxxxxx>]

On 06/12/2015 10:57 PM, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH v2 COLOPre 11/13] tools/libxl: rename remus 
> device to checkpoint device"):
> > On Fri, Jun 12, 2015 at 02:30:46PM +0100, Wei Liu wrote:
> > > On Mon, Jun 08, 2015 at 11:43:15AM +0800, Yang Hongyang wrote:
> > > > -    (-18, "REMUS_DEVOPS_DOES_NOT_MATCH"),
> > > > -    (-19, "REMUS_DEVICE_NOT_SUPPORTED"),
> > > > +    (-18, "CHECKPOINT_DEVOPS_DOES_NOT_MATCH"),
> > > > +    (-19, "CHECKPOINT_DEVICE_NOT_SUPPORTED"),
> > > You should add two new error numbers.
> > And in that case you might also need to go through all places to make
> > sure the correct error numbers are return. I.e. old remus code path
> > still returns REMUS error code and new CHECKPOINT code path returns new
> > error code.
> >
> > I merely speak from API backward compatibility point of view. If you
> > think what I suggest doesn't make sense, please let me know.
> To me this line of reasons prompts me to ask: what would be wrong with
> leaving the word REMUS in the error names, and simply updating the
> descriptions ?
>
> After all AFIACT the circumstances are very similar.  I don't think it
> makes sense to require libxl to do something like
>     rc = were_we_doing_colo_not_remus ? CHECKPOINT_BLAH : REMUS_BLAH;
>
> Please to contradict me if I have misunderstood...
COLO and REMUS both are checkpoint device. We use checkpoint device layer
as a more abstract layer for both COLO and REMUS, come to the error code,
these can be used by both COLO and REMUS. So we don't distinguish if we
are doing COLO or REMUS, uses are aware of what they're executing(colo
or remus).

> Ian.
> .
--
Thanks,
Yang.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel