From: Ian Campbell <ian.campbell@citrix.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Cc: Kevin <kevin.tian@intel.com>,
wei.liu2@citrix.com, Ian.Jackson@eu.citrix.com,
qemu-devel@nongnu.org, xen-devel@lists.xen.org,
stefano.stabellini@citrix.com
Subject: Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c
Date: Tue, 24 Mar 2015 09:51:44 +0000 [thread overview]
Message-ID: <1427190704.21742.318.camel@citrix.com> (raw)
In-Reply-To: <55112498.2040108@intel.com>
On Tue, 2015-03-24 at 16:47 +0800, Chen, Tiejun wrote:
> All guys,
>
> Sorry to bother you.
>
> I have a question to two files, tools/python/xen/lowlevel/xc/xc.c and
> tools/python/xen/lowlevel/xl/xl.c. Who is a caller to those methods like
> pyxc_methods[] and pyxl_methods[]?
They are registered with the Python runtime, so they are called from
Python code. The first member of the struct is the pythonic function
name, e.g. from xc.c:
{ "domain_create",
(PyCFunction)pyxc_domain_create,
METH_VARARGS | METH_KEYWORDS, "\n"
"Create a new domain.\n"
" dom [int, 0]: Domain identifier to use (allocated if zero).\n"
"Returns: [int] new domain identifier; -1 on error.\n" },
defines a method called domain_create, in the xen.lowlevel.xc namespace.
> And how should we call these approaches?
I'm not sure what you are asking here.
> In my specific case, I'm trying to introduce a new flag to each a device
> while assigning device. So this means I have to add a parameter, 'flag',
> into
>
> int xc_assign_device(
> xc_interface *xch,
> uint32_t domid,
> uint32_t machine_sbdf)
>
> Then this is extended as
>
> int xc_assign_device(
> xc_interface *xch,
> uint32_t domid,
> uint32_t machine_sbdf,
> uint32_t flag)
>
> After this introduction, obviously I should cover all cases using
> xc_assign_device(). And also I found this fallout goes into these two
> files. For example, here pyxc_assign_device() is involved. Currently it
> has two parameters, 'dom' and 'pci_str', and as I understand 'pci_str'
> should represent all pci devices with SBDF format, right?
It appears so, yes.
> But I don't know exactly what rule should be complied to construct this
> sort of flag into 'pci_str', or any reasonable idea to achieve my goal?
If it is non-trivial to fix them IMHO it is acceptable for the new
parameter to not be plumbed up to the Python bindings until someone
comes along with a requirement to use it from Python. IOW you can just
pass whatever the nop value is for the new argument.
Ian.
next prev parent reply other threads:[~2015-03-24 9:51 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-23 1:17 [Qemu-devel] [v3][PATCH 0/2] libxl: try to support IGD passthrough for qemu upstream Tiejun Chen
2015-03-23 1:17 ` [v3][PATCH 1/2] libxl: introduce libxl__is_igd_vga_passthru Tiejun Chen
2015-03-23 1:17 ` [Qemu-devel] " Tiejun Chen
2015-03-23 1:17 ` [Qemu-devel] [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind Tiejun Chen
2015-03-23 1:17 ` Tiejun Chen
2015-03-24 8:47 ` [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c Chen, Tiejun
2015-03-24 9:51 ` Ian Campbell
2015-03-24 9:51 ` Ian Campbell [this message]
2015-03-24 10:15 ` [Qemu-devel] " Chen, Tiejun
2015-03-24 10:20 ` Ian Campbell
2015-03-24 10:31 ` Chen, Tiejun
2015-03-24 10:31 ` [Qemu-devel] " Chen, Tiejun
2015-03-24 10:40 ` Ian Campbell
2015-03-25 1:18 ` Chen, Tiejun
2015-03-25 1:18 ` [Qemu-devel] " Chen, Tiejun
2015-03-25 10:26 ` Ian Campbell
2015-03-25 10:26 ` [Qemu-devel] " Ian Campbell
2015-03-26 0:44 ` Chen, Tiejun
2015-03-26 0:44 ` [Qemu-devel] " Chen, Tiejun
2015-03-24 10:40 ` Ian Campbell
2015-03-24 10:20 ` Ian Campbell
2015-03-24 10:15 ` Chen, Tiejun
2015-03-24 8:47 ` Chen, Tiejun
2015-03-24 14:50 ` [v3][PATCH 2/2] libxl: introduce gfx_passthru_kind Ian Campbell
2015-03-24 14:50 ` [Qemu-devel] " Ian Campbell
2015-03-25 1:10 ` Chen, Tiejun
2015-03-25 1:10 ` [Qemu-devel] " Chen, Tiejun
2015-03-25 10:32 ` Ian Campbell
2015-03-25 10:32 ` [Qemu-devel] " Ian Campbell
2015-03-26 0:53 ` Chen, Tiejun
2015-03-26 0:53 ` [Qemu-devel] " Chen, Tiejun
2015-03-26 10:06 ` Ian Campbell
2015-03-26 10:06 ` [Qemu-devel] " Ian Campbell
2015-03-27 1:29 ` Chen, Tiejun
2015-03-27 1:29 ` [Qemu-devel] " Chen, Tiejun
2015-03-27 9:54 ` Ian Campbell
2015-03-27 9:54 ` [Qemu-devel] " Ian Campbell
2015-03-30 1:28 ` Chen, Tiejun
2015-03-30 9:19 ` Ian Campbell
2015-03-30 9:19 ` [Qemu-devel] " Ian Campbell
2015-04-01 1:05 ` Chen, Tiejun
2015-04-01 1:05 ` [Qemu-devel] " Chen, Tiejun
2015-04-01 8:45 ` Ian Campbell
2015-04-01 9:18 ` Chen, Tiejun
2015-04-01 9:18 ` [Qemu-devel] " Chen, Tiejun
2015-04-01 9:53 ` Ian Campbell
2015-04-01 9:53 ` [Qemu-devel] " Ian Campbell
2015-04-01 8:45 ` Ian Campbell
2015-03-30 1:28 ` Chen, Tiejun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1427190704.21742.318.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=kevin.tian@intel.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@citrix.com \
--cc=tiejun.chen@intel.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.