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] simple backend, frontend

To: Keir Fraser <keir.fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] simple backend, frontend
From: Georgios Portokalidis <georgios.portokalidis@xxxxxxxxx>
Date: Thu, 18 Nov 2004 17:57:46 +0000
Cc: Deepak Manohar <mjdeepak@xxxxxxxxx>, mark.williamson@xxxxxxxxxxxx, andrew.warfield@xxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 18 Nov 2004 17:59:41 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=qm9kyxa3Y5l1jNpneEhxIpQdlE6hJZMMBWATGQ5DxWzCdj2M95O2P1nuI0JDJcZX7wy76JguyA/ISykgTjeaIP85EPZ/PFvARFwC5AkRw2ln7NCG0AqDEY0jfddxPo9VwG1WM1NLfyN1uU9TW6EeMlS/7I5NgdULp6KHkJmSWqc=
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <E1CUqQc-0004Ut-00@xxxxxxxxxxxxxxxxx>
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>
References: <ef73505041118094561031fbb@xxxxxxxxxxxxxx> <E1CUqQc-0004Ut-00@xxxxxxxxxxxxxxxxx>
Reply-to: Georgios Portokalidis <georgios.portokalidis@xxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
On Thu, 18 Nov 2004 17:50:41 +0000, Keir Fraser
<keir.fraser@xxxxxxxxxxxx> wrote:
> > 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.

Yeah, I thought the idea of a proxy module, but it is still a pain writing it.
The way things are now the subtype is used to determine the action.
The proxy module could actually offer a different interface to forward
messages to xen....
It's definitely one of the todos
>  -- 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

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