This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-tools] xenbus block device support

To: xen-tools@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-tools] xenbus block device support
From: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Date: Wed, 10 Aug 2005 19:32:43 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Delivery-date: Wed, 10 Aug 2005 18:30:49 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-tools-request@lists.xensource.com?subject=help>
List-id: Xen control tools developers <xen-tools.lists.xensource.com>
List-post: <mailto:xen-tools@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i

the 7 changesets at http://www.cl.cam.ac.uk/~cl349/xenbus/ add support
for xenbus setup/teardown of block devices.  They apply cleanly against
57d57bd7127ffbb6ae0ad6f27a270d5952555c16.  It would be very helpful if
people could give these a try and then I'll check them in after the
weekend.  There are also a few known issues and it would be really great
if these could be addressed before I check the changes in:
- xend support is very rough.  We want to get rid of the controller and
  device objects but what's there now is maybe a bit too straight forward.
- file: devices don't get unbound when the domains exit
- domain destruction while the devices are accessed is not handled
- store updates from xend don't use transactions and the code in the
  drivers to handle this short coming is complicated.  On the other
  hand it should make the drivers more robust.

The broken file: support actually points to a more serious issue - binding
of the loopback devices should actually happen in the backend domain and
the command to bind/unbind the device should be passed to the backend
via the store.

For transactional store updates, I think an interface similar to the existing
addChild interface would be nice, i.e. you start a transaction and get a
DBMap object which you can update, and there would then be a command to
perform the transaction once all updates are done.


Xen-tools mailing list