Re: [Xen-devel] [PATCH] xencommons: Attempt to load blktap driver

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.08.12 at 11:33, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2012-08-31 at 10:03 +0100, Jan Beulich wrote:
>> >>> On 31.08.12 at 10:40, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > From what you say I think we want to modprobe blktap if blktap2 didn't
>> > exist.
>> > 
>> > blktap2 isn't actually a xenbus backend driver (since it uses blkback to
>> > do the guest facing bit) so I don't think a xen-backend: alias is
>> > available. I can't see any other aliases defined in the code in either
>> > the 2.6.18-xen tree, the SLES 2.6.32.12-0.7.1 kernel (which is the
>> > latest I happen to have to hand) or a mainline kernel. If there is
>> > something else we should be trying please let me know.
>> 
>> There's a "devname:xen/blktap-2/control" alias in our SLE11 SP2
>> and newer openSUSE ones (as of 2.6.35). Whether that's fully
>> appropriate to be there and/or to be used as a modprobe
>> argument I'm not sure though.
>> 
>> The bad thing about the "blktap" name is that that's also the
>> name of the blktap1 driver in the 2.6.18 tree and its forward
>> ports, but I don't think there's anything we can reasonably do
>> about that.
> 
> I thought about that. Most kernels which have blktap1 nowadays also have
> blktap2 so the number of systems where you would actually end up with
> only blktap1 loaded is pretty small. It's also AFAIK reasonably harmless
> other than the memory usage etc.
> 
> In retrospect renaming blktap2->blktap ni pvops was a stupid idea (I can
> say that since it was my idea...)
> 
>>  So I'm fine with the change you suggest from that
>> perspective (whether to use the module alias pointed out ).
> 
> Can I take that as an
> Acked-by: Jan Beulich <JBeulich@xxxxxxxx>
> ?

Yes, feel free to do so.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel