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

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

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/)

Just that it's bit cryptic and the netlink.py module makes things easy.
>> 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.


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

> 
>> But as starters, people would be able to play with remus via xl (just
>> memory checkpointing).
>> What do you folks think?
> 
> I think it would be a good start to get just that bit in, as you say
> people can play with it and it also lays the groundwork for the rest.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel