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

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





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


 


Rackspace

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