WARNING - OLD ARCHIVES

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

xen-devel

Re: [Xen-devel] simple backend, frontend

To: Georgios Portokalidis <georgios.portokalidis@xxxxxxxxx>
Subject: Re: [Xen-devel] simple backend, frontend
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 18 Nov 2004 17:50:41 +0000
Cc: Keir Fraser <keir.fraser@xxxxxxxxxxxx>, Deepak Manohar <mjdeepak@xxxxxxxxx>, mark.williamson@xxxxxxxxxxxx, andrew.warfield@xxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 18 Nov 2004 17:53:24 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 18 Nov 2004 17:45:45 GMT." <ef73505041118094561031fbb@xxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> I have actually written some code for xen & xend allowing you to
> request the creation of an event channel and share a memory page. It's
> still work in progress, but it works fine. No crashes, very simple
> communication scheme.

Yes, for some things, where xend does not need to keep state on the
channel (e.g., network address info, blkdev info) then having a way to
get xend to just be a dumb channel for your evtchn/shared-mem info is
undoubtedly a good idea.

> The only possible problem i believe is the
> ctrl_if_register_receiver(). I think you can only register a single
> receiver for each control message type per domain. So even with a
> generic shared channel mechanism you will be able to use it just from
> a single driver/module.

Use the subtype field, or create another field within your message, to
demux on. Then have a small proxy module that registers with
ctrl_if.c but then demuxes and forwards the message to the appropriate
driver based on the demux field. You could have drivers register with
the proxy module instead of ctrl_if.

 -- Keir


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel