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

Re: [Xen-devel] xenbus_backend_client.c / xenbus_client.c merger


  • To: Kieran Mansley <kmansley@xxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Mon, 19 Feb 2007 15:17:02 +0000
  • Delivery-date: Mon, 19 Feb 2007 07:16:23 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdUOQGYQEmFLMAsEduvRQAX8io7RQ==
  • Thread-topic: [Xen-devel] xenbus_backend_client.c / xenbus_client.c merger

On 19/2/07 14:00, "Kieran Mansley" <kmansley@xxxxxxxxxxxxxx> wrote:

> Although I don't know the full history, it looks like at some point
> linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_backend_client.c was
> created to hold "backend only" code that would otherwise be in
> linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_client.c.
> 
> However, the code in xenbus_backend_client.c isn't currently specific to
> the backend - it just happens to be that no frontends use it.  At least
> that's how it looks to me.

Currently we have a model that frontends supply memory for ring buffers,
which backends map into their kernel address space. Where is the memory
coming from that your frontend maps? Is it appropriate to be using grant
table entries to refer to and map that memory?

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