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

Re: [Xen-devel] x2d2


  • To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
  • From: Andrew Warfield <andrew.warfield@xxxxxxxxx>
  • Date: Wed, 19 Jan 2005 16:44:16 +0000
  • Cc: Anthony Liguori <anthony@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 19 Jan 2005 18:39:56 +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=JivxR9BjaC1isfiUoZTgigENQLsoMlaSUcH4bg2FK8Z6yLeDqZBGk+6+6o3KEQ/nyC7nETSQEUQvdf9fSP7+DwqRaOFFXGnD7Iivp1o3b/vwben6Z3R1cLJ1BRN14gDgAVkzyUJGi4PNcBZ5M+GaI7KhOHdJZUm/csrmwWXHO3Y=
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>

Another option is to give the console drivers their own device channel
(i.e. take them off the control rings) and then just provide a
separate backend for them.  From there dom0 could export them however
it wanted to without depending on the other control tools at all.

a.

On Wed, 19 Jan 2005 16:36:45 +0000, Ian Pratt <Ian.Pratt@xxxxxxxxxxxx> wrote:
> > Andrew Warfield wrote:
> >
> > >We are in the process of some fairly major revisions to the control
> > >tools.  I think that the general expectation is that 3.0 will show
> > >some pretty big changes to the control interfaces and tools.  The
> > >unstable tree now has a control switch (xcs) which sits under xend and
> > >
> > >
> > Wow.  I wrote the same exact thing about a week or two ago.
> >
> > I took a slightly different approach though.  I opened a unix domain
> > socket to receive messages on and also opened up ptys for each domain.
> >
> > The daemon takes care of multiplexing and demultiplexing the messages so
> > if your app sends a message, it will only get that response.
> >
> > What are your thoughts on this approach?  I particularly like the idea
> > of piping the console data to a pty.
> 
> We thought about the pty approach, but resisted it because we
> thought that in most setups there'd need to be a daemon running
> in user-space to export the console (typically over the network),
> and hence it wasn't worth the effort of turning it into a pty in
> the kernel.
> 
> The current approach also minimizes the amount of OS-specific Xen
> privileged interface code, which keeps the people interested in
> using OSes other than Linux in domain 0 happy.
> 
> I could be persuaded, though...
> 
> Ian
>


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

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