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

Re: [Xen-devel] /proc/xen/xenbus supports watch?




On 20 Sep 2005, at 12:01, Rusty Russell wrote:

By providing a kernel device node we
make it look exactly like talking through a socket, so libxenstore is
basically unchanged.  By each open using a separate page to talk to
xenstored, we don't have to hold the kernel lock, nor worry about tool
errors/crashes screwing the kernel's store page. xenstored restarts are
transparent.  On migration, we can simply force close (unmap page,
return EBADF), which libxestore can treat exactly like the xenstored
restart case with sockets, reconnect and re-xmit.

None of this really adds weight for or against muxing versus page-per-transaction.

If accesses from domU userspace are always communicated via the kernel device node, userspace gets no direct access to the transport page and so the kernel can ensure the page does not get corrupted. Also there's no need to hold the kernel lock for the duration of the user-space transaction if we mux multiple transactions onto a single page -- as independent transactions it is up to xenstored to deal with sync issues between them. We would need to hold the lock for short periods during the transaction (e.g., while accessing the shared transport page) but we would not be holding it continuously.

As for client handling of migration/restart -- it's an API issue that is independent of the underlying 'wire' transport.

 -- Keir


_______________________________________________
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®.