From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH RFC 1/2] tools/libxc: Improved xc_{topology, numa}info functions. Date: Wed, 12 Mar 2014 10:41:09 +0000 Message-ID: <532039C5.1070100@citrix.com> References: <1393499497-9162-1-git-send-email-andrew.cooper3@citrix.com> <1393499497-9162-2-git-send-email-andrew.cooper3@citrix.com> <1394613247.31942.45.camel@Abyss> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6177590476724393925==" Return-path: In-Reply-To: <1394613247.31942.45.camel@Abyss> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: Ian Jackson , Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org --===============6177590476724393925== Content-Type: multipart/alternative; boundary="------------030804000908050805030302" --------------030804000908050805030302 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On 12/03/14 08:34, Dario Faggioli wrote: > On Thu, 2014-02-27 at 11:11 +0000, Andrew Cooper wrote: >> These two new functions provide a substantially easier-to-use API, where libxc >> itself takes care of all the appropriate bounce buffering. >> > So, because of the stalled discussion on patch 2 of this series, this > patch was hardly considered, I guess, is that so? > > Personally, I think this is an improvement in its own right, and I'd > like to have it, independently from the CPUID stuff. Are you up, > perhaps, for submitting it as a separate patch? > > One thing I'm not sure is why you're introducing new *_bounced variants, > rather than going ahead and modifying xc_topologyinfo() and > xc_numainfo() directly. libxc is not an API we committed to keep > stable, is it? > > Thanks and Regards, > Dario > I certainly can modify the original ones directly. When developing, it in the 4.4 freeze, and I wanted my changes to easily co-exist with libxc. (If you notice, these patches are in XenServer trunk for easy deployment against our entire set of weird & wacky hardware). If there general agreement that making the old xc_{topology,numa}info() functions have the prototype and behaviour of my _bounced variants, then I will happy do that, and send some fixup to make libxl work against it. ~Andrew --------------030804000908050805030302 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit On 12/03/14 08:34, Dario Faggioli wrote:
> On Thu, 2014-02-27 at 11:11 +0000, Andrew Cooper wrote:
>> These two new functions provide a substantially easier-to-use API, where libxc
>> itself takes care of all the appropriate bounce buffering.
>>
> So, because of the stalled discussion on patch 2 of this series, this
> patch was hardly considered, I guess, is that so?
>
> Personally, I think this is an improvement in its own right, and I'd
> like to have it, independently from the CPUID stuff. Are you up,
> perhaps, for submitting it as a separate patch?
>
> One thing I'm not sure is why you're introducing new *_bounced variants,
> rather than going ahead and modifying xc_topologyinfo() and
> xc_numainfo()  directly. libxc is not an API we committed to keep
> stable, is it?
>
> Thanks and Regards,
> Dario
>


I certainly can modify the original ones directly.  When developing, it in the 4.4 freeze, and I wanted my changes to easily co-exist with libxc.  (If you notice, these patches are in XenServer trunk for easy deployment against our entire set of weird & wacky hardware).

If there general agreement that making the old xc_{topology,numa}info() functions have the prototype and behaviour of my _bounced variants, then I will happy do that, and send some fixup to make libxl work against it.

~Andrew

--------------030804000908050805030302-- --===============6177590476724393925== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6177590476724393925==--