Xen project Mailing List

On Thu, Jan 19, 2012 at 1:10 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

On Thu, 2012-01-19 at 19:00 +0000, Shriram Rajagopalan wrote:
> On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>
> > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> >>
> >>
> >> I do have a set of initial patches for xl remus. Since the "script="
> >> support doesnt exist for disk configurations (required to support both
> >> DRBD and tapdisk backends).
> >>
> >> So, currently I only have memory checkpointing functionality. No disk
> >> buffering.
> >> Will submit it in a day or so.
> >>
> >> About network buffering:
> >> a. There is code to install and manipulate the network buffer via
> >> netlink messages. And its in python. While the "xl remus" control flow
> >> starts off from C. Either I implement the C equivalent
> >> of the python code or call the python code from C (this is C->python
> >> and not the other way around). Please correct me if I am wrong.
> >
> > Wrong about what?
> >
> > I don't think calling Python from C in libxl is a good idea. Forking a
> > process would be better but best would be to just implement the C
> > version. Is there a libnetlink which can help with this sort of thing?
> >
>
> There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)

I meant an existing generic netlink library, not something specific to
the Xen python bindings.

Debian has libnl{1,2,3} pacakges in it -- why not use them?

Yes I know. I have toyed with them. The qdisc names are hardcoded in their libraries.
So, even if one installs sch_plug (qdisc name "plug"), the library wont recognize it!
I do have my own version of the library (patched) but as you said, I dont want to
bundle that stuff with xen.

There is no reason why this sort of generic library should be in the Xen
tree. (lets be honest, there's no reason why the python bindings to such
a library should be in Xen either)

> Just that it's bit cryptic and the netlink.py module makes things easy.

Calling into python from libxl is not acceptable.

I understand. I wouldnt have done it either :)

> >> b. The kernel module (sch_plug): Last I knew, the network
> >> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
> >> the tree moved to 3.0 series, it got axed off.
> >
> > My understanding was that a competing module with similar/equivalent
> > functionality was the one which eventually made it upstream (I don't
> > know the names). Unfortunately this probably means that Remus needs to
> > switch over to the upstreamed thing.
> >
>
> I don't think so. When I submitted the patch for sch_plug to netdev,
> nobody (even the qdisc maintainer) mentioned anything about an
> equivalent module.

I must have been mistaken then. Why is your module not upstream?

Beats me.

> > There is no "Xen Linux tree" like there used to be and we wouldn't want
> > to carry a module which isn't ready for upstream in any case. (Your
> > module wasn't axed, it just wasn't/isn't upstream).
> >
> >> While I am still, convincing the netdev folks into accepting this
> >> module upstream, I have a link in the remus wiki, asking people to
> >> download/compile the module. (People do this only after shooting a
> >> couple of "Remus is not working" emails to the mailing list)
> >
> > You can't detect this at runtime and print an error message? Do you not
> > get ENOSYS or something when you try and use the module?
>
> I do. And the emails are despite that.

It sounds like there would be no helping these people.

> >> As an alternative, I could pull it into the tools/remus/ folder (just
> >> like the way it used to be before the pvops kernels) and compile it as
> >> part of the tools compilation process.
> >
> > The build doesn't include building a kernel any more so I don't think
> > this will work.
>
>
> But can we at least include the source, make file and a readme telling
> people to install the required packages needed to compile a module.

We are trying to get out of the business of bundling every bit of
infrastructure which someone happens to want to use with Xen in the Xen
source repository, so, no, I don't think we can/should include the
source to this Linux kernel module in the Xen tree.

You could perhaps add a README or some Remus documentation directing
people to an external tarball with the module in it, but from what you
say above it doesn't sound like that will help very much (and neither
would having that tarball in the tree).

Of course the right solution is to get your module merged upstream.

Ian.

Re: [Xen-devel] RFC: Still TODO for 4.2?