Re: Re: [PATCH] Remus breaks the build

[Brendan Cully <brendan@cs.ubc.ca>]

On Friday, 13 August 2010 at 21:25, Dulloor wrote:
> On Fri, Aug 13, 2010 at 2:14 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> >  On 08/13/2010 12:42 PM, Brendan Cully wrote:
> >> I assume you're talking about this snippet of tools/remus/kmod/Makefile:
> >>
> >> $(MAKE) -C $(KERNELDIR) SUBDIRS=`pwd` modules
> >>
> >> which expects to find a Makefile in $KERNELDIR but does the actual
> >> building in place, in the tools/remus/kmod directory (unless the
> >> kernel build system has changed recently?). I thought this was a
> >> pretty standard way to build out-of-tree kernel modules.
> >
> > I don't ever build the kernel out of the Xen tree.  In general, it
> > assumes the kernel tree has already been configured and built, which may
> > not be true if you're doing a parallel build, or if you're building the
> > Xen tree piecewise.
> >
> >> I'm not sure why this is causing you problems (is it?), but if you're
> >> willing to carry sch_queue in the pvops tree, I'd be happy to drop
> >> tools/remus/kmod in the unstable tree.
> >
> > Yes, I'm happy to include it.  Do you have a git reference I can merge from?
> 
> My understanding is that we don't need any out-of-tree modules, if
> linux is built with CONFIG_IFB.
> Also, that IFB isn't something available on 2.6.18 (and maybe
> 2.6.27?), where we will need to build these modules.
> 
> Is that right ? And, if thats the case, isn't it better to fold these
> drivers into 2.6.18 (2.6.27 ?) and
> support Remus conditional on IFB for pvops tree ?

Remus actually uses two modules. One is sch_queue, a Linux queueing
discipline that queues outbound guest traffic until the machine state
that produced it has been committed at the backup. This is the one
that we're talking about moving into the pvops tree (after I've tested
it -- I'm having the customary day-long fight getting Xen running
smoothly after having not updated for a while).

We need a second module (IFB or IMQ, depending on the kernel version)
because Linux queueing disciplines only operate on a device's outbound
traffic. Since Remus runs in dom0, it sees the guest's outbound
traffic as _inbound_ traffic on a VIF device. So IMQ/IFB is used to
redirect that incoming VIF traffic to a virtual intermediate device
with the sch_queue queueing discipline installed on it.