From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaLV2-0002ED-EL for qemu-devel@nongnu.org; Tue, 24 Mar 2015 05:51:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaLUy-0004hq-Dj for qemu-devel@nongnu.org; Tue, 24 Mar 2015 05:51:52 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:35758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaLUy-0004hH-AH for qemu-devel@nongnu.org; Tue, 24 Mar 2015 05:51:48 -0400 Message-ID: <1427190704.21742.318.camel@citrix.com> From: Ian Campbell Date: Tue, 24 Mar 2015 09:51:44 +0000 In-Reply-To: <55112498.2040108@intel.com> References: <1427073466-16956-1-git-send-email-tiejun.chen@intel.com> <1427073466-16956-3-git-send-email-tiejun.chen@intel.com> <55112498.2040108@intel.com> Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] One question to lowlevel/xl/xl.c and lowlevel/xc/xc.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Chen, Tiejun" Cc: Kevin , wei.liu2@citrix.com, Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org, xen-devel@lists.xen.org, stefano.stabellini@citrix.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.