On 05/25/2010 08:25 AM, Avi Kivity wrote:
On 05/25/2010 04:17 PM, Anthony Liguori wrote:
On 05/25/2010 04:14 AM, Avi Kivity wrote:
On 05/24/2010 10:38 PM, Anthony Liguori wrote:
- Building a plugin API seems a bit simpler to me, although I'm to
sure if I'd get the
idea correctly:
The block layer has already some kind of api (.bdrv_file_open,
.bdrv_read). We
could simply compile the block-drivers as shared objects and
create a method
for loading the necessary modules at runtime.
That approach would be a recipe for disaster. We would have to
introduce a new, reduced functionality block API that was supported
for plugins. Otherwise, the only way a plugin could keep up with
our API changes would be if it was in tree which defeats the
purpose of having plugins.
We could guarantee API/ABI stability in a stable branch but not
across releases.
We have releases every six months. There would be tons of block
plugins that didn't work for random sets of releases. That creates a
lot of user confusion and unhappiness.
The current situation is that those block format drivers only exist in
qemu.git or as patches. Surely that's even more unhappiness.
Confusion could be mitigated:
$ qemu -module my-fancy-block-format-driver.so
my-fancy-block-format-driver.so does not support this version of
qemu (0.19.2). Please contact
my-fancy-block-format-driver-devel@xxxxxxxxxxxx
The question is how many such block format drivers we expect. We now
have two in the pipeline (ceph, sheepdog), it's reasonable to assume
we'll want an lvm2 driver and btrfs driver. This is an area with a
lot of activity and a relatively simply interface.
If we expose a simple interface, I'm all for it. But BlockDriver is not
simple and things like the snapshoting API need love.
Of course, there's certainly a question of why we're solving this in
qemu at all. Wouldn't it be more appropriate to either (1) implement a
kernel module for ceph/sheepdog if performance matters or (2) implement
BUSE to complement FUSE and CUSE to enable proper userspace block devices.
If you want to use a block device within qemu, you almost certainly want
to be able to manipulate it on the host using standard tools (like mount
and parted) so it stands to reason that addressing this in the kernel
makes more sense.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
