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

Re: [Xen-devel] [PATCH] [XEN] [ACM] [2/2] Restructuring ACM-related code

To: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [XEN] [ACM] [2/2] Restructuring ACM-related code in do_domctl
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 23 Apr 2007 08:59:22 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 23 Apr 2007 00:56:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OF4C971F10.50A436A9-ON852572C6.00134ABC-852572C6.0013DE06@xxxxxxxxxx>
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
Thread-index: AceFfU1wjDTgifFwEdusfQAWy6hiGQ==
Thread-topic: [Xen-devel] [PATCH] [XEN] [ACM] [2/2] Restructuring ACM-related code in do_domctl
User-agent: Microsoft-Entourage/11.3.3.061214
On 23/4/07 04:37, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

The 'internal structure' that represents the label of the domain is maintained through a pointer connected to the domain structure. For that reason I would intend to hold the lock on the policy until the domain has been added to the list of domains.

In this case it probably makes sense to maintain your own domain list within your ACM subsystem, so that you can always find any domain that has been registered with you via your domain_create hook. I suggest a policy-specific structure pointed at by struct domain (void *security ?). You can dynamically allocate this struct on domain_create() and it can contain a list_head to chain domains through. You can also hide SSID in there (it’s going to need to move out of generic struct domain when XSM comes along, as sHype won’t be the only game in town any longer).

> That is, an architecture where you have a ‘pre-doing-stuff’ hook and
> a ‘pre-destroying-stuff’ hook, where the latter is also called when
> the doing-stuff action turns out to fail, is nicer than pre/post hooks.

I'll change that in do_domctl().

If you do it in domain_create() itself you’ll also get your hook called for creation of dom0. That will probably avoid some nasty hacking around (like you have right now in chwall_post_domain_create, because the pre-hook is missed out for dom0).

 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel