[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c

From: Chen, Tiejun
Subject: Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c
Date: Wed, 25 Mar 2015 09:18:34 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 2015/3/24 18:40, Ian Campbell wrote:
On Tue, 2015-03-24 at 18:31 +0800, Chen, Tiejun wrote:
NB, the libxl ones are broken and not even compiled right now, you can
ignore them.

Looks this is still compiled now.

xc is, xl is not, I am sure of that.

Indeed, you're right :)

I don't know what the semantics of flag is, if it is per SBDF then I

Yes, this should be a flag specific to a SBDF.

You know, I'm working to fix RMRR completely. Based on some discussion
about that design ( I assume you may read that thread previously :) ),
now we probably need to pass a flag to introduce our policy.

Unless you have a concrete requirement to expose RMRR via the Python
bindings to libxc (i.e. you know somebody is using them) then I think
you should not bother.

Actually my problem is that, I need to add a new parameter, 'flag', like this, xc_assign_device(xxx,xxx,flag). So if I don't refine xc.c, tools can't be compiled successfully. Or maybe you're suggesting I may isolate this file while building tools, right?

Making RMRR work via the (C) interface to libxl used by xl and libvirt
is sufficient for a new in tree feature.



suppose if you really wanted to expose this here then you would need to
invent some syntax for doing so.


When I finish this I will send you to review technically.

Again, really appreciate your clarification to me.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]