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/
Home Products Support Community News


Re: [Xen-devel] DomU-Dom0 communication question

To: <rileyrd@xxxxxxxxx>
Subject: Re: [Xen-devel] DomU-Dom0 communication question
From: mk.xen-devel@xxxxxxxxxxxxxxx
Date: Wed, 02 May 2007 15:06:09 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 02 May 2007 12:04:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 5/2/07, Ryan Riley <rileyrd@xxxxxxxxx> wrote:
> > I am looking at backend/frontend drivers and I don't think it would work
> for what I want to do as fron/back ends don't have any devices associated
> with it.
> > 
> Hmm, it sounds like you may be a bit confused regarding how the split
> drivers work.  

Yes, I am :-)

> For any useful frontend/backend device each side ends up
> being two drivers in one.  One is the frontend/backend driver, the other is
> the device that the OS sees.  For example, the networking frontend has all
> of the code the being a Xen frontend driver (event channels, probe handling,
> etc) and is also a network device that the guest interacts with.  In a sense
> it registers itself as two drivers. 

That is the driver I was going through to get an idea how it works. I see the 
network adapter registration part, but since I am not familiar with network 
drivers APIs I got confused what exactly is going on. 

> You could definitely write a split driver that has character devices on both
> ends that share data.  My backend driver for the project I mentioned above
> is exactly that.  (Frontend kernel puts data onto a ring buffer, backend
> kernel reads it off and makes it available as a character device.) 

Sounds exactly what I need, except I was thinking to have messages in both 

> This probably sounds bad, but if you can get away with it I would do
> everything is user space and send your arbitrary data/buffers over the
> network link.  Trust me when I say that you'll lose less hair that way. 

I think, the split drivers give me a better control for the task I am doing. I 
do not want to rely on network being setup correctly.

> If you decide to go the split driver route, I can supply you with my code. 
> It isn't pretty, but it may help you out.  Let me know if you're interested.

I am definitely  interested! I was out of writing Linux drivers for quite some 
time and I appreciate any help I can get.



Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>