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()? Is a ChardevClass providing init() and connect() usable with DEFINE_PROP_CHR()? 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()?
