From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 11 of 11] Some automatic NUMA placement documentation Date: Fri, 8 Jun 2012 15:03:26 +0100 Message-ID: <4FD2062E.1040308@eu.citrix.com> References: <20423.35189.904831.64711@mariner.uk.xensource.com> <1338478895.15014.60.camel@Solace> <20434.1446.507811.744249@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20434.1446.507811.744249@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , "xen-devel@lists.xen.org" , Dario Faggioli List-Id: xen-devel@lists.xenproject.org On 08/06/12 15:01, Ian Jackson wrote: > Dario Faggioli writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement documentation"): >> On Thu, 2012-05-31 at 16:08 +0100, Ian Jackson wrote: >>> In general I would prefer to see docs come in the same patch but I >>> guess I can read it here: >> I can put it there. Would you recommend _moving_ it in the source file o >> also leaving a copy, o maybe just some pointers, here? > In general I don't mind whether API docs are in a separate file or in > the source headers. What we have here is sufficiently complex that it > seems to merit its own file. A reference to it from libxl.h would be > appropriate. > >> Right, that is of couse an option, and I thought about going that way >> for quite a while. However, what I think is best for libxl is to provide >> a set of building blocks for its user to be able to implement the actual >> heuristics. > The difficulty with this is that this is supposedly becoming a stable > API. If we change the approach later, we may want to change the API. > Do we know clearly enough what building blocks are needed and what > they should be like ? > > I think it would be easier, at this stage for 4.2, simply to offer a > single `do something sensible' heuristic, and then think about more > complicated control by the caller for 4.3. In fact, I think it would probably be better to take Ian Campbell's suggestion and either just do it in xl completely (with no libxl changes) or do it entirely with libxl, with no external interface. Then we'll have something better than nothing, and the whole 4.3 dev cycle to come up with a good interface we can commit to. -George