[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Compilation problems: oldstyle/xenlinux 2.6.38, blktap2



Jan,

--On 19 October 2011 08:29:48 +0100 Jan Beulich <JBeulich@xxxxxxxx> wrote:

On 18.10.11 at 20:57, Alex Bligh <alex@xxxxxxxxxxx> wrote:
As far as I can tell from the Makefile, both directories are always
built:

  obj-$(CONFIG_XEN_BLKDEV_TAP2)           += blktap2/ blktap2-new/

What's the difference between blktap2 and blktap2-new? Should only
one be built? I can't see a config option that switches between them.

Yeah, assuming he (as always) just took our patches, the this isn't
meant to be used with CONFIG_XEN_BLKDEV_TAP2=y (which we
never do). Setting it to =m will get you going. I'll see if I can adjust
this (but only in the current patch sets) so that it won't end up trying
to build both into the kernel.

Thanks.

Apologies in advance that this email contains several no doubt
stupid questions:

Stupid question #1: I take it that "our patches" means SUSE's? Is there a git tree I can pull patches from rebased against something modern (e.g. 2.6.38)? What I'm doing is creating a kernel based on Ubuntu Natty, and I currently have it working with one great blob of Xen patches, rather than the original git paches which would be better.

I'm quite happy to publish the tree if that's useful to people, but
I get the feeling it would be more useful if it had the original commits
rather than them squashed together in one blob. I've got to the stage
of it compiling fine (+/- blktap2), packaging fine, but untested.

Under the same assumption - the difference between the two is that
-new is what is in the pv-ops kernel (but not upstream), while the
other is the forward port from the 2.6.18 tree.

Stupid question #2: so, if I'm running with Xen 3.3.x, it won't use
any of the pvops stuff. Will a xenlinux/oldstyle kernel ever use
any of the pvops stuff? If blktap2 is compiled as a module, how does
it know which module to load (blktap2 or blktap2-new) apart from
manual insmod?

I know one option is to just build blktap instead and ignore blktap2.
If I want to run this as a dom0 for Xen 3.3, will I lose anything
by not having blktap2?

Quite obviously your kernel will lack support for any of the tap2:
protocols.

Stupid question #3: If this kernel is running as dom0 for 3.3.x,
would it use any of the blktap2 stuff anyway? I'm working from
memory here but didn't that come after 3.3.1? And if I'm wrong, aren't
I going to want to build blktap2 (presumably not -new) as a built-in
(i.e. "y")? Perhaps I'm missing what tap2 does vs. tap.

--
Alex Bligh

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.