From mboxrd@z Thu Jan 1 00:00:00 1970 From: mk.xen-devel@simplecheck.net Subject: Re: DomU-Dom0 communication question Date: Wed, 02 May 2007 15:06:09 -0400 Message-ID: <31835741.705661178132769762.JavaMail.servlet@perfora> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: rileyrd@gmail.com Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 5/2/07, Ryan Riley 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 directions. > 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. Thanks. Max