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

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2015/3/24 17:51, Ian Campbell wrote:
> On Tue, 2015-03-24 at 16:47 +0800, Chen, Tiejun wrote:
> > All guys,
Thanks for your reply.

> > 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
Sorry I don't understanding this. So seems you mean instead of xl, this 
is called by the third party user with python?
> name, e.g. from xc.c:
>      { "domain_create",
Otherwise, often we always perform `xl create xxx' to create a VM. So I 
think this should go into this flow like this,
xl_cmdtable.c:main_create()
        |
        + create_domain()
                |
                + libxl_domain_create_new()
                        |
                        + do_domain_create()
                                |
                                + ....
Right?

>        (PyCFunction)pyxc_domain_create,
So I don't see 'pyxc_domain_create' is called. Or I'm missing something...

>        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.
If you can give a real case to call this, things couldn't be better :)

> > 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.
Should I extend this 'pci_str' like "Seg,bus,device,function:flag"? But 
I'm not sure if I'm breaking the existing usage since like I said, I 
don't know what scenarios are using these methods.
Thanks
Tiejun

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