[Top][All Lists]

[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

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v9 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"
Date: Mon, 20 Feb 2017 14:21:43 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

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
   a VM).

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().


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]