WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Use of otherend field in xenbus_device

To: xen-devel@xxxxxxxxxxxxxxxxxxx, ewan@xxxxxxxxxxxxx
Subject: [Xen-devel] Use of otherend field in xenbus_device
From: harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 29 Nov 2005 18:10:53 +0000
Delivery-date: Tue, 29 Nov 2005 18:18:25 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Ewan,

    My USB code is failing to unregister its watch correctly because
when it registers the watch it sets the watch.node to use the otherend
string in the xenbus_device and this string is freed in
xenbus_dev_remove before my driver's remove function is called to
unregister the watch.

    Using the otherend string directly during suspend and resume also
looks dodgy because the string is changed before resume is called and
resume unregisters the old watch.

    I think I either have to make a local copy of the string which my
driver can hang onto until after the watch is unregistered or I have to
change the xenbus_probe code such that the lifetime of the string spans
probe<->suspend and resume<->remove and probe<->remove.  In the latter
case I'd also have to change my code such that the watch was
unregistered on suspend and registered on resume rather than
unregistered and re-registered in resume.

    Was your intent here for drivers to make a copy of this string if
they needed it or for them to use the xenbus_device one?  For the time
being I'm going to go with making a local copy of the string.  Please
let me know if this is the wrong approach.

Thanks,

Harry.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Use of otherend field in xenbus_device, harry <=