[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v9 1/2] block/vxhs.c: Add support for a new bloc
Re: [Qemu-devel] [PATCH v9 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"
Mon, 20 Feb 2017 14:21:43 +0000
On Sun, Feb 19, 2017 at 02:30:53PM -0800, Ashish Mittal wrote:
> v9 changelog:
> (1) Fixes for all the review comments from v8. I have left the definition
> of VXHS_UUID_DEF unchanged pending a better suggestion.
If I understand correctly libvxhs has a global instance ID for choosing
the SSL client certificate.
I would get rid of iio_init()/iio_fini() or at least avoid passing in
anything besides int32_t version. Let iio_open() take an instance ID
and iio_cb_t callback.
This gives applications more flexibility. For example, you can write a
utility that copies data from instance A disk#1 to instance B disk#2.
Or an application with special requirements can process callbacks for
different disks in different iio_cb_t functions if it wishes. Today
both of these things are not possible due to iio_init().
QEMU block drivers must keep in mind:
1. There may be more than one BlockDriverState (i.e. multiple disks for
2. Each BlockDriverState may be access from a different thread (i.e.
it's best if the library avoids global state so thread-safety is
So avoid the global iio_init() call. Pass parameters into iio_open()
from the QEMU command-line instead of using globals.
If the library wants to pool global resources like SSL/TCP connections
it can do that internally in a thread-safe way. There's no need to make
configuration global via iio_init().
Description: PGP signature