Re: [Xen-devel] [4 Patches] New blktap implementation, 2nd try

[Kevin Wolf <kwolf@xxxxxxx>]

Andrew Warfield schrieb:
> The current ioemu: extensions duplicate the blktap control and data
> path code and suck them into qemu.  I think this is probably about as
> bad as duplicating drivers, given that it makes it quite difficult to
> evolve the block extension interface.

It's difficult anyway. Probably that's the reason why you're proposing a
revolution instead of evolution. ;-)

But agreed, duplicating this code is as bad as duplicating drivers,
still it is less code duplicated (and only duplicated, not completely
changed). I did this only because tapdisk was meant to disappear eventually.

> The patch doesn't create three versions of drivers -- the third
> version that you refer to is just the deprecated blktap code that's
> being replaced.  So how about this:  we drop in the new code, and
> delete the old version of blktap altogether.  Then let's have a think
> about what the right way to unify the drivers is.

I think that's one of the points I made in my long mail. At least we
should replace the old blktap completely so that the duplication won't
become even worse.

> I like your idea of being able to drop driver implementations into
> both tapdisk and qemu.  However, I think that when you look at the
> code you'll find that the new tapdisk interface provides a lot more
> than what the qemu interfaces currently provide.  A good solution to
> this would be to just run tapdisk as the block virtualization layer
> even when qemu is being used without Xen.

Ask the upstream qemu mailing list. I'm quite sure they'll tell you that
it won't happen. One reason is that blktap is limited to Linux and qemu
isn't.

And what's the interface you mean? blktap's struct tap_disk certainly
looks smaller than qemu's struct BlockDriver. But even if tapdisk has a
lot more than qemu provides, I think we would still win much if we can
share at least the code for common functionality.

Kevin

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