On 05/25/2010 05:01 PM, Kevin Wolf wrote:
The current situation is that those block format drivers only exist in
qemu.git or as patches. Surely that's even more unhappiness.
The difference is that in the current situation these drivers will be
part of the next qemu release, so the patch may be obsolete, but you
don't even need it any more.
The next qemu release may be six months in the future. So if you're not
happy with running qemu.git master or with patching a stable release,
you have to wait.
If you start keeping block drivers outside qemu and not even try
integrating them, they'll stay external.
Which may or may not be a problem.
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.
What's the reason for not having these drivers upstream? Do we gain
anything by hiding them from our users and requiring them to install the
drivers separately from somewhere else?
Six months.
--
error compiling committee.c: too many arguments to function
--
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
