Re: [Xen-devel] simple backend, frontend

[Georgios Portokalidis <georgios.portokalidis@xxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel