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


Re: [Xen-devel] sHype changeset causes error in domU creation

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] sHype changeset causes error in domU creation
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Thu, 23 Jun 2005 11:05:28 -0400
Cc: Steven Hand <Steven.Hand@xxxxxxxxxxxx>, George Washington Dunlap III <dunlapg@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Stefan Berger <stefanb@xxxxxxxxxx>
Delivery-date: Thu, 23 Jun 2005 15:04:30 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <041ba709dab4516e782402a0740fd415@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote on 06/23/2005 05:48:12 AM:

> On 23 Jun 2005, at 04:01, Stefan Berger wrote:
> > This is a problem that comes with an FC 4 install and the newer python
> > that comes along with it.
> > Below a patch that solves the problem. ( default=~0 would also work )
> >
> > Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> Steve applied this patch, but I'd strongly argue for 0 as the default 
> ssid value. I don't know if this this is a hard change to make?

Hi Keir, we already started to change the default ssid (to 0). The change 
is not much work but will need testing. We will have a patch in a few 

> As an aside, I also don't like the name of the policy hypercall and 
> policy control tools. Can we call them 'acm_policy' or 
> 'security_policy' or something like that? Calling them 'policy' with no 
> further qualification is too vague.

This is a good suggestion as well. We are going to make the name change
to security_policy. acm_policy is a bit too restrictive since the security
architecture will generally involve more than just the current access 

>   Cheers,
>   Keir

Xen-devel mailing list