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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2015-03-24 at 18:15 +0800, Chen, Tiejun wrote:
> 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?

Yes, tools/python/xen is the python bindings for various C libraries
supported by Xen.

NB, the libxl ones are broken and not even compiled right now, you can
ignore them.

> 
> > 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?

Yes, xl is written in C not python so tools/python doesn't enter the
picture.

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

Chances are that there are no intree users of this code any more, xend
would have used it at one time with something like:
        import xen.lowlevel.xc
        xc = xen.lowlevel.xc.xc()
        xc.domain_create()
etc.

> >
> >> 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.

Like I said in the paragraph above, if it is complicated then it is fine
to ignore this new parameter from Python.

I don't know what the semantics of flag is, if it is per SBDF then I
suppose if you really wanted to expose this here then you would need to
invent some syntax for doing so.

Ian.


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