From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: xenbus_backend_client.c / xenbus_client.c merger Date: Mon, 19 Feb 2007 15:17:02 +0000 Message-ID: References: <1171893626.4099.27.camel@moonstone.uk.level5networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1171893626.4099.27.camel@moonstone.uk.level5networks.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Kieran Mansley , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 19/2/07 14:00, "Kieran Mansley" 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