On 15.10.25 09:56, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy <[email protected]> writes:
For further vhost-user-blk backend-transfer migration realization we
want to give it (vhost-user-blk) a possibility (and responsibility) to
decide when do connect.
For incoming migration we'll need to postpone connect at least until
early stage of migrate-incoming command, when we already know all
migration parameters and can decide, are we going to do incoming
backend-transfer (and get chardev fd from incoming stream), or we
finally need to connect.
With this patch, we only provide new macro, to define chardev property,
later it will be used in vhost-user-blk instead of DEFINE_PROP_CHR.
There is no "later" in this series.
The new macro is called DEFINE_PROP_CHR_NO_CONNECT().
Then, vhost-user-blk will call qemu_chr_connect() by hand when needed
(for example through qemu_chr_fe_wait_connected(), which is already
called in vhost_user_blk_realize_connect()).
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Excuse my quick & ignorant questions...
I understand ChardevClass provides either methods init() and connect(),
or method open().
Is a ChardevClass providing open() usable with
DEFINE_PROP_CHR_NO_CONNECT()?
Good question. It's usable, but it will work like simple DEFINE_PROP_CHR.
I should improve it somehow. Better is to fail than go unexpected way.
Is a ChardevClass providing init() and connect() usable with
DEFINE_PROP_CHR()?
Yes, and works correctly.
Could the code do the right thing based on presence of open() vs. init()
and connect() instead of DEFINE_PROP_CHR()
vs. DEFINE_PROP_CHR_NO_CONNECT()?
No, because, the frontend should be prepared to work with new _NO_CONNECT (e.g.,
call _connect() by hand when needed). There are a lot of frontends, which
expect already connected backend, updating them all would be big (and
unnecessary) work.
--
Best regards,
Vladimir
