|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Compilation problems: oldstyle/xenlinux 2.6.38, blktap2
>>> On 19.10.11 at 22:40, Alex Bligh <alex@xxxxxxxxxxx> wrote:
> --On 19 October 2011 08:29:48 +0100 Jan Beulich <JBeulich@xxxxxxxx> wrote:
> 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.
You could pull openSUSE's kernel-source-*.src.rpm-s, or go to
http://kernel.opensuse.org/git. That's a fine grained as you will
be able to get it.
> 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?
I'm trying to merge with drivers that make it upstream, but we're
not going to use the base pvops infrastructure until we're going to
switch over (in the not too far future, hopefully).
> If blktap2 is compiled as a module, how does
> it know which module to load (blktap2 or blktap2-new) apart from
> manual insmod?
That's how it's expected to work (or in SLES possibly by marking only
one of them supported, which will prevent the other from getting
loaded).
>> 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.
Indeed, tap2 appeared in 4.0.0 only, so with 3.3.x you should be
safe to leave it off.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|