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

Re: [Xen-devel] Backend in user space, how is its kernel dev unregistered?



Keir Fraser <keir.fraser@xxxxxxxxxxxxx> writes:

> On 04/03/2009 19:51, "Markus Armbruster" <armbru@xxxxxxxxxx> wrote:
>
>>>> 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.
>>> 
>>> Presumably these should watch xenstore themselves and tear down state when
>>> they see state changes from the frontend, or the corresponding xenstore
>>> directory disappear completely. Just like in the kernel's xenbus_probe.c.
>>> 
>>>  -- Keir
>> 
>> Stupid question: how can a user space driver get *kernel* devices
>> unregistered?
>
> Maybe I misunderstand the problem. I don't know much about pvfb or pvkbd.
>
>  -- Keir

Let me elaborate.

Backend device registration is split between xenbus_probe.c
(registering) and the backend device driver (unregistering).  When a
device node shows up in xenstore, xenbus_probe_node() calls
device_register().  When the backend driver sees the frontend shut down,
it calls device_unregister().  For an example see frontend_changed() in
drivers/xen/blkback/xenbus.c.

The vfb and vkbd backends live in user space, i.e. there is no backend
driver in the kernel.  device_unregister() never gets called.  This is a
resource leak.

Does this explain the problem sufficienctly?

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.