[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |