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-api

Re: [Xen-API] Re: Xen API call today 8am PST

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] Re: Xen API call today 8am PST
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Fri, 16 Feb 2007 07:51:29 -0500
Cc: xen-api-bounces@xxxxxxxxxxxxxxxxxxx, xen-api@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 16 Feb 2007 04:50:41 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070216101801.GC24587@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

xen-api-bounces@xxxxxxxxxxxxxxxxxxx wrote on 02/16/2007 05:18:01 AM:

> On Wed, Feb 14, 2007 at 10:50:59AM -0500, Sean Dague wrote:
>

>
> Stefan asked about the recent sHype/ACM Xen-API patch, and what it would take
> to get that into the tree.  I said that, since I don't have expertise in this
> area, I'm going to need consensus from the other security folks with regards
> to the API.  I'd be looking for an agreement that XSM would drop into the same
> framework, in particular.


Here's my/our current thinking. It's difficult to imagine what an API for any future policy might look like that allows to do policy-specific operations and I'd rather have a policy-specific API than a generic one that is more work to program against (and circumvents all that great serialization/deserialization facilities availablle in libxen. -- see the other mail). So we regard the ACM policy as an example of a policy like VIF, VBD and VTPM are examples of devices. The latter three have their own classes with methods and properties that are specific to each device-type for porviding funcationality specific to each device. Similar is true with policies. So we'll have a policy class 'XSPolicy' that allows you to administer the policy on the system, put a new one in and load it into the hypervisor and get a reference to the current policy. That reference is then used to make policy-specific actions on a policy-specific class, i.e., ACMPolicy for manipulations of that type of policy. Someone inventing a new policy subsystem for Xen needs to come up with a new class, extend xend's logic and extend the HV, which is all true anyway no matter how the API looks like, since ACM-specific code won't likely apply to any other policy.

>
> Previously, I suggested that this would be a good thing to discuss at the next
> Xen Summit when everyone's together, and I still think that that's a good
> idea.


The only concern here is that afaik the next Xen summit is only in April.

   Stefan

>
> That's all I remember from the call.  If there's anything I've missed, please
> pipe up!
>
> Ewan.
>
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
<Prev in Thread] Current Thread [Next in Thread>