Re: x2d2

[Andrew Warfield <andrew.warfield@gmail.com>]

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@cl.cam.ac.uk> 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