From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: Re: Domgrps/SchedGrps Merge RFC: domgrps-vmm Date: Tue, 12 Feb 2008 00:05:11 +0000 Message-ID: <20080212000511.GC4483@implementation> References: <1CB9F0D9-ADBD-4368-836C-94CAB62296B2@tycho.ncsc.mil> <20080211220738.GA11545@silverwood.ncultra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: <20080211220738.GA11545@silverwood.ncultra.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Mike D. Day" Cc: Chris , xen-devel List-Id: xen-devel@lists.xenproject.org Mike D. Day, le Mon 11 Feb 2008 17:07:38 -0500, a écrit : > So a domain can only belong to one group at a time. Would it ever be > useful for a domain to belong to more than one group? This type of > restriction seems to work against the idea of a general grouping > concept. Right. > For example, all domains that belong to a scheduling group > (assuming we eventually merge domgrp and schedgrp) would automatically > be removed from a scheduling group if added to any other type of > group. Which makes sense, doesn't it? > This argues for keeping different types of groups under different > grouping infrastructures unless we can figure out a way for a domain > to have multiple group memberships. It may be too complicated to do so. Yes, usually group mecanisms are just hierarchical rather than being so generic as to permit several membership. I guess the common pitfall is when enumerating groups, you may see a domain several times, and such strange effects. Samuel