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

Re: [Xen-devel] [PATCH][4] xen: remove TapdiskException when add device



Yeah, right. we should add the TapdiskException to release self.info
when tapdisk handle failed.
and we should consider that any upper toolstack will dig into Xend
code, it is important

On Fri, Mar 21, 2014 at 6:44 PM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> On Fri, Mar 21, 2014 at 02:14:01PM +0800, æä wrote:
>> >From a3005f45b578db0c035f03b08714357dcd53d06c Mon Sep 17 00:00:00 2001
>> From: Yi Li <peteryili@xxxxxxxxxxx>
>> Date: Fri, 21 Mar 2014 14:08:52 +0800
>> Subject: [PATCH][4] xen: remove TapdiskException when add device
>>
>> using the VmError instead of TapdiskException when add device
>>
>> Signed-off-by: Yi Li <peteryili@xxxxxxxxxxx>
>> ---
>>  tools/python/xen/xend/server/BlktapController.py |    5 +----
>>  1 files changed, 1 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/python/xen/xend/server/BlktapController.py
>> b/tools/python/xen/xend/server/BlktapController.py
>> index 60079eb..c8e5e24 100644
>> --- a/tools/python/xen/xend/server/BlktapController.py
>> +++ b/tools/python/xen/xend/server/BlktapController.py
>> @@ -198,9 +198,6 @@ class Blktap2Controller(BlktapController):
>>          self.waitForBackend_destroy(backpath)
>>          TapdiskController.destroy(path)
>>
>> -class TapdiskException(Exception):
>> -    pass
>> -
>>  class TapdiskController(object):
>>      '''class which encapsulates all tapdisk control operations'''
>>
>> @@ -229,7 +226,7 @@ class TapdiskController(object):
>>          stdout.close()
>>          stderr.close()
>>          if rc:
>> -            raise TapdiskException('%s failed (%s %s %s)' % \
>> +            raise VmError('%s failed (%s %s %s)' % \
>>                                         (args, rc, out, err))
>>          return out
>>
>
> After this change BlktapController raises VmError just as other
> controllers do. On the flip side any out-of-tree users of
> TapdiskException are broken. Not sure if there's any such user, but it's
> probably safe to remove this as the breakage should be easy to spot and
> fix, and I doubt that any upper toolstack will dig into Xend code to use
> its internal abstraction...
>
> Wei.
>
>> --
>> 1.7.1

_______________________________________________
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®.