Re: [PATCH RFC 1/2] tools/libxc: Improved xc_{topology, numa}info functions.

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1483 bytes --]

On mer, 2014-03-12 at 10:41 +0000, Andrew Cooper wrote:
> On 12/03/14 08:34, Dario Faggioli wrote:
> 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).
> 
Sure, I know. That's why I sent this 'kind-of-ping' :-)

> 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.
> 
Of course. Let's hear maintainers. FWIW, I vote for it. As you already
say in the cover letter of the series, the current implementation in
both libxc and libxl is a pain to use and maintain, and set a very ba
example for people wanting to do similar things.

In fact, it was me that, as one of my first contributions to Xen,
(re)implemented libxl_get_numainfo(), out of inspiration from
libxl_get_cpu_topology()! :-/

So, to summarize my view, let's switch the existing to yours ASAP.
Ian-s? :-)

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel