On 15.10.25 10:55, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy <[email protected]> writes:
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.
QMP command
{"execute": "qom-list-types", "arguments": {"implements": "chardev"}}
shows me 23 subtypes of "chardev". Could miss a few not in this build.
Converting them all would be work. It's not a prohibitive amount of
work, though. Whether it's worth our while is not for me to judge.
I'm not sure we talk about the same thing.
Converting all chardevs to new API .init + .connect is feasible, and I say
in cover letter:
If the design gets general approval, I'll try to update other
chardev backends, to avoid supporting two different initialization
APIs in future.
But converting all chardev users to DEFINE_PROP_CHR_NO_CONNECT is another
thing:
git grep DEFINE_PROP_CHR | wc -l
71
- it would be a huge work, and no benefits. Having a default of "already
connected chardev" seems reasonable. No reason to teach these 70 frontends
to call _connect() by hand.
-
frontend/backend is always misleading terminology for me, especially when
we have more than two components in the system :/
--
Best regards,
Vladimir
