Skip to contentSkip to conversation

Fix "xm list --long" listing for removed devices

PATCH In review Dan Smith 2 participants 3 messages Nov 30, 2005 – Dec 1, 2005

lore
Share & tools
lore

Dan Smith

author
#0 lore raw

PATCH 1/1 Fix "xm list --long" listing for removed devices

This patch makes xend clean up information about devices at removal so that the long xm listing is consistent with reality.

This will close bug #416.

# HG changeset patch
# User [email protected]
# Node ID c7b558e88f08037f68ba2fc5f6c5361517075f62
# Parent 2b45f4c5a565b24c06e0a25e920ff104eeb6eb62 Finish up bug #416. Remove devices from the config stored inside XendDomainInfo so that "xm list --long" is consistent with reality.

tools/python/xen/xend/XendDomainInfo.py +28 -1
diff -r 2b45f4c5a565 -r c7b558e88f08 tools/python/xen/xend/XendDomainInfo.py
@@ -31,7 +31,7 @@
 
 import xen.lowlevel.xc
 from xen.util import asserts
-from xen.util.blkif import blkdev_uname_to_file
+from xen.util.blkif import blkdev_uname_to_file, blkdev_name_to_number
 
 from xen.xend import image
 from xen.xend import sxp
@@ -1275,6 +1275,33 @@
         self.info['device'].append((dev_type, dev_config))
         return self.getDeviceController(dev_type).sxpr(devid)
 
+
+    def device_destroy(self, type, dev):
+        """Destroy a device.
+
+        @param type: device type
+        @param dev: device id
+        """
+
+        try:
+            device = int(dev)
+        except:
+            device = blkdev_name_to_number(dev)
+
+        for t,c in self.info['device']:
+            if t == type:
+            
+                currentDev = sxp.child_value(c, "dev")
+                try:
+                    currentDev = int(currentDev)
+                except:
+                    currentDev = blkdev_name_to_number(currentDev)
+
+                if currentDev == device:
+                    self.info['device'].remove((t,c))
+                    break
+
+        self.destroyDevice(type, dev)
 
     def device_configure(self, dev_config, devid):
         """Configure an existing device.
tools/python/xen/xend/server/SrvDomain.py +1 -1
diff -r 2b45f4c5a565 -r c7b558e88f08 tools/python/xen/xend/server/SrvDomain.py
@@ -155,7 +155,7 @@
                          req)
 
     def op_device_destroy(self, _, req):
-        return self.call(self.dom.destroyDevice,
+        return self.call(self.dom.device_destroy,
                          [['type', 'str'],
                           ['dev',  'str']],
                          req)
Signature · 5 lines
-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [email protected]

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#1 lore raw
Quoted 6 lines · Dan Smith

This patch makes xend clean up information about devices at removal so that the long xm listing is consistent with reality.

This will close bug #416.

Dan, sorry, but this patch breaks 02_network_attach_detach. Vifs don't have a 'dev' entry in their config, so the attempt to read that returns None, which you end up passing to blkdev_name_to_number.

In any case, I would rather have the device-specific complexity in the DevController subclasses. If you look at xen/xend/server/blkif.py, it already has to find a device ID from a device name (which in this case it does by looking through the store rather than XendDomainInfo's config, but the effect is the same). I'd want to keep these things together. I'm not sure how this would all plumb through to XendDomainInfo -- it might be nice to have a mapping from device ID to config so that it wasn't necessary to iterate over info['device'] and go grubbing around in the configs there.

If you want to re-work this, feel free, otherwise I'll be taking your basic idea and rejigging it so that the network-detach is not broken, and so that we get that bug fixed in the next day or so.

Ewan.

author
#2 lore raw

EM> this patch breaks 02_network_attach_detach.

Oops, does it? I ran xm-test over it, but I must have confused that with the other attach-detach test that is failing right now. Sorry about that.

EM> In any case, I would rather have the device-specific complexity in EM> the DevController subclasses.

Yep, definitely. I was too focused on the block device. Very stupid of me.

EM> If you want to re-work this, feel free, otherwise I'll be taking EM> your basic idea and rejigging it so that the network-detach is not EM> broken, and so that we get that bug fixed in the next day or so.

I'll rework it ASAP.

Signature · 4 lines
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: [email protected]