From: Dave McCracken <dmccr@us.ibm.com>
To: ckrm-tech@lists.sourceforge.net
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
Date: Mon, 30 Oct 2006 12:16:04 -0500
User-Agent: KMail/1.9.5
Cc: dev@openvz.org, linux-kernel@vger.kernel.org, devel@openvz.org
References: <20061030103356.GA16833@in.ibm.com> <20061030024320.962b4a88.pj@sgi.com> <20061030170916.GA9588@in.ibm.com>
In-Reply-To: <20061030170916.GA9588@in.ibm.com>
Organization: IBM LTC
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610301116.04780.dmccr@us.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1305
Lines: 26

On Monday 30 October 2006 11:09 am, Srivatsa Vaddagiri wrote:
> Hierarchy has implications in not just the kernel-user API, but also on
> the controller design. I would prefer to progressively enhance the
> controller, not supporting hierarchy in the begining.
> 
> However you do have a valid concern that, if we dont design the user-kernel
> API keeping hierarchy in mind, then we may break this interface when we
> latter add hierarchy support, which will be bad.
>
> One possibility is to design the user-kernel interface that supports
> hierarchy but not support creating hierarchical depths more than 1 in the
> initial versions. Would that work?

Is there any user demand for heirarchy right now?  I agree that we should 
design the API to allow heirarchy, but unless there is a current need for it 
I think we should not support actually creating heirarchies.  In addition to 
the reduction in code complexity, it will simplify the paradigm presented to 
the users.  I'm a firm believer in not giving users options they will never 
use.

Dave McCracken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/