[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] simple backend, frontend



> It is absolutely possible to use libxc to do all of this without
> xend,
Yes, but it's distinctly awkward to actually start communicating
between domains without xend being involved.  Essentially, you need
some way to communicate which machine frame and event channel number
to use, and, short of copying and pasting stuff on the console, xend's
pretty much the only game in town.

> I'm just not sure off the top of my head if you will be able to have
> two listeners coexisting on /dev/eventchan, and whether xend will
> play nicely with another listener.
The current /dev/evtchn implementation can't cope with two processes
openning it at once.  I have a somewhat out of date, hacked over
version which can available from http://om.elsie.org.uk/temp/evtchn.c.
It should be possible to just copy this over the top of
drivers/xen/evtchn/evtchn.c, but, as I say, it's a little out of date,
and comes with no warranties.

xend itself has no problems whatsoever with someone sharing the event
channel interface, though, provided you're careful not to bind to any
events which it uses. (i.e. if you allocate an event channel, you can
use it just fine; if xend's allocated an event channel, stay away).

> Obviously, adding support for new backend/frontend protocols is
> something that we want to make very easy for development... This is
> something that has come up several times in the past couple of weeks
> and we are actively looking into the best solution.  In the short
> term, you might want to experiment with a C implementation along side
> xend, or try digging in to the python... I'll keep you posted as soon
> as anything arises.
> 
> a.
> 
> On Thu, 11 Nov 2004 14:21:01 -0500, Deepak Manohar <mjdeepak@xxxxxxxxx> wrote:
> > Hi,
> > 
> >  Ive looked at the blkifdrivers.txt.
> > 
> >  Wht Im confused about is - both in the netif backend and the blkif
> > backend the initial communication is with xend. The blkif initially
> > sends - BLKIF_DRIVER_STATUS_UP
> > the netif backend sends an equivalent. Im assuming that Xend
> > differentiates between the two and sends different response either
> > CMSG_BLKIF_BE_CREATE or CMSG_NETIF_BE_CREATE.
> > 
> >  Now if I need to add another custom backend using the same method as
> > the netif or blkif backends dont I have to modify Xend as well?
> > 
> > Is there a simpler way of establishing event channels between domains
> > by directly accessing the API in xen/common/event_channel.c
> > 
> >  Some assumptions that Im making - the frontend will be started only
> > after the backend is running. Im primarily going to be using this
> > frontend/backend for transferring large data between a user domain and
> > the control domain.  So I will have to establish shared mem pages as
> > well.
> > 
> > Thanks.
> > 
> > Deepak
> > 
> > On Thu, 11 Nov 2004 16:18:09 +0000, Andrew Warfield
> > 
> > 
> > <andrew.warfield@xxxxxxxxx> wrote:
> > > You may also want to look at docs/misc/blkif-drivers-explained.txt,
> > > which has a textual description of how the split block drivers work.
> > > Alex went through it about a week ago and brought it up to date with
> > > the (then) current sources.
> > >
> > > a.
> > >
> > >
> > >
> > >
> > > On Thu, 11 Nov 2004 16:07:09 +0000, Mark A. Williamson
> > > <mark.williamson@xxxxxxxxxxxx> wrote:
> > > > In the event you can't find a simple example, feel free to ask 
> > > > questions about
> > > > the existing block / net drivers.  You'll find that the frontends are 
> > > > much
> > > > simpler so you may want to look at those first.  I also found that the
> > > > backend for network was easier to understand than the block backend.
> > > >
> > > > You should also look at domain_controller.h, which defines all of the 
> > > > control
> > > > messages used to set up the shared memory and event channels.
> > > >
> > > > HTH,
> > > > Mark
> > > >
> > > >
> > > >
> > > > On Thursday 11 Nov 2004 15:37, Deepak Manohar wrote:
> > > > > Hi all,
> > > > >
> > > > > Does anyone have a custom backend, frontend pair?  Preferably a very
> > > > > simple one that simply sets up eventchannels and shared memory pages.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Deepak
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email is sponsored by:
> > > > > Sybase ASE Linux Express Edition - download now for FREE
> > > > > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > > > > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> > > > > _______________________________________________
> > > > > Xen-devel mailing list
> > > > > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > > > > https://lists.sourceforge.net/lists/listinfo/xen-devel
> > > >
> > > > -------------------------------------------------------
> > >
> > >
> > > > This SF.Net email is sponsored by:
> > > > Sybase ASE Linux Express Edition - download now for FREE
> > > > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > > > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > > > https://lists.sourceforge.net/lists/listinfo/xen-devel
> > > >
> > >
> >
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel

-- 
One day, I'm going to get an Alice-bot to answer all my email for me,
and see how long it takes people to notice.

Attachment: pgpUoqNE8kw9P.pgp
Description: PGP signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.