WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [PATCH] xenctld - a control channel multiplexing daemon
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Fri, 21 Jan 2005 09:55:56 -0600
Delivery-date: Fri, 21 Jan 2005 15:39:09 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
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>
Organization: IBM
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
As I mentioned in earlier posts, we implemented a small multiplexing
daemon for the control channels in Xen.  It was designed to help
understand how Xen worked and not initially as a management framework. 
I'm posting it because I think some people might find it useful.

It's very much like xcs.

I also included two example tools for xenctld.  One thing that I see in
common between these two apps is that they both implemented better
interfaces to Xen.  Here's what I propose:

1) Change xcs to use unix domain sockets.
2) Add support to xcs to export ptys (storing info in the filesystem
much the same way xenctld does)
3) Change xenctld tools to use xcs.
4) Factor out most of xen interaction in xcs to standard libraries.

I see a three level architecture, the first level being highly portable
libraries that simplify interacting with Xen.  This would target every
platform Xen runs on.

The second level would be a daemon that is not as portable but still
very portable (for instance, you may have a posix daemon, a win32
daemon, etc.).

The third level would be simple applications that present a
platform-level interface (here it might make sense to have a set of
Linux tools, a set of BSD tools, etc.).

Thoughts?  I'm willing to code these things up.  Just want to make sure
it's agreeable first.

You can get a copy of xenctld at:

http://www.cs.utexas.edu/users/aliguori/xenctld-0.0.1.tar.bz2

Regards,

-- 
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@xxxxxxxxxx
Phone: (512) 838-1208





-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel