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] "virtual cluster" debug support

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] "virtual cluster" debug support
From: Kip Macy <kip.macy@xxxxxxxxx>
Date: Sat, 19 Mar 2005 14:41:12 -0800
Cc: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxxxx>, ian.pratt@xxxxxxxxxxxx
Delivery-date: Sat, 19 Mar 2005 22:44:49 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BWJgJfIqWZh5O/fCRN0scm8TMxC9wpBxjJuT7MNuBwFMxFEgI+UxQaAyStCKoMcusy9V38e4DTScMoO/NPfKFwJ00AdH8r/wiZPkZPtO1vZ4Fq1p4M0D6O0S0MltnavfcLq5V7Z0lqgYQGnMTfO9lwdb1aMovwXSb4Cm9gh7sGk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D1E375E@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1E375E@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: Kip Macy <kip.macy@xxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> (though create will fill in a default of groupid = domid).

That restriction is only a current limitation of the tools. I simply
haven't taken the time to set the option at runtime.

> I'm not keen on the proliferation of dom0 ops, and I expect we'll merge
> a number of them into a 'get/set domain parameter' 
operation at some

What is wrong with {GET/SET}DOMAININFO? These can be done at run-time.
If you look, you'll see that I explicitly handle the case of removing
a domain from an existing group before adding it to another.

> point, but for the moment, I think the best soloution is adding a
> DOM0_SETDOMAINGROUP.

I'm perfectly happy to do that, but I'd like to know why SETDOMAININFO
doesn't fit the bill.

I would also appreciate feedback on the correctness of the locking.

Thanks.

        -Kip


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel