From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <aliguori@us.ibm.com>
Subject: Re: Change in xm interface
Date: Fri, 17 Feb 2006 16:13:47 -0600
Message-ID: <43F64A9B.4080800@us.ibm.com>
References: <43F63AB8.6070407@us.ibm.com>
	<20060217215805.GI3848@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <20060217215805.GI3848@localhost.localdomain>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Ewan Mellor <ewan@xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

Ewan Mellor wrote:
> Your concern is perfectly reasonable.  On that note though, could I
> emphasise
>
>   a) Screen-scraping xm is a bad idea.  There is an interface straight
>   into xend that one can use for integration (the same interface that xm
>   uses).  This will avoid such hackery, and make it an awful lot easier
>   to maintain backwards compatibility.  xm is for humans to use, not
>   tools.
>   
I agree with you completely and will take the time to point out that 
libvirt uses the S-Expression/HTTP interface so you can just use that :-)
>   b) There is no guarantee that any interface inside domain 0, be it
>   to the tools, or even to Xen, are fixed.  The only interfaces that are fixed
>   at the moment are the interfaces used by guests.  Everything else is
>   subject to change at any time.  Of course, it's in everyone's
>   interests that these interfaces become fixed in the future, but
>   there's plenty of work that has to go into them yet before we could
>   claim that they are supportable in the long term.
>   
Yup.
> That list is xen-devel, for the moment.  I'm not sure there's any value
> in having a separate list -- anyone who's developing products that sit
> on top of Xen _really_ needs to be reading xen-devel anyway -- the
> project simply isn't mature enough for you to get away without doing
> that.
>   
Ok.  Always good to reiterate this occasionally :-)

Regards,

Anthony Liguori
> Ewan.
>
>