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] Backend in user space, how is its kernel dev unregistered?

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Backend in user space, how is its kernel dev unregistered?
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Wed, 04 Mar 2009 20:02:27 +0100
Delivery-date: Wed, 04 Mar 2009 11:02:50 -0800
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
There's a curious asymmetry in how Xen backend devices are registered
and unregistered.

Registering is the job of xenbus_probe.c: it watches xenstore, and when
a device node shows up, it calls device_register().

Unregistering is the device driver's job: it watches xenstore, and when
it sees the front end shut down, it calls device_unregister().

But what if the device driver is in user space?  vfb and vkbd are.  I
can't see how their kernel devices can ever get unregistered.

If that is true, any ideas on how to plug the leak?

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