From: Markus Armbruster <armbru@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: marcandre.lureau@redhat.com, pbonzini@redhat.com,
berrange@redhat.com, eduardo@habkost.net,
qemu-devel@nongnu.org, raphael@enfabrica.net,
yc-core@yandex-team.ru, d-tatianin@yandex-team.ru
Subject: Re: [PATCH v3 5/7] chardev/char: introduce .init() + .connect() initialization interface
Date: Wed, 15 Oct 2025 09:49:27 +0200 [thread overview]
Message-ID: <87plaofvug.fsf@pond.sub.org> (raw)
In-Reply-To: <76945924-ed5e-4365-95c8-a8f752d7ad03@yandex-team.ru> (Vladimir Sementsov-Ogievskiy's message of "Wed, 15 Oct 2025 09:58:39 +0300")
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:
> On 15.10.25 09:50, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:
>>
>>> We'll need a possibility to postpone connect step to later point in
>>> time to implement backend-transfer migration feature for vhost-user-blk
>>> in further commits. Let's start with new char interface for backends.
>>>
>>> .init() takes QAPI parameters and should parse them, called early
>>>
>>> .connect() should actually establish a connection, and postponed to
>>> the point of attaching to frontend. Called at later point, either
>>> at time of attaching frontend, either from qemu_chr_wait_connected().
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
>>> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>> [...]
>>
>>> diff --git a/include/chardev/char.h b/include/chardev/char.h
>>> index 429852f8d9..ebadaf3482 100644
>>> --- a/include/chardev/char.h
>>> +++ b/include/chardev/char.h
>>> @@ -63,6 +63,7 @@ struct Chardev {
>>> CharBackend *be;
>>> char *label;
>>> char *filename;
>>> + bool connect_postponed;
>>> int logfd;
>>> int be_open;
>>> /* used to coordinate the chardev-change special-case: */
>>> @@ -225,6 +226,7 @@ QemuOpts *qemu_chr_parse_compat(const char *label, const char *filename,
>>> bool permit_mux_mon);
>>> int qemu_chr_write(Chardev *s, const uint8_t *buf, int len, bool write_all);
>>> #define qemu_chr_write_all(s, buf, len) qemu_chr_write(s, buf, len, true)
>>> +bool qemu_chr_connect(Chardev *chr, Error **errp);
>>> int qemu_chr_wait_connected(Chardev *chr, Error **errp);
>>>
>>> #define TYPE_CHARDEV "chardev"
>>> @@ -259,10 +261,28 @@ struct ChardevClass {
>>> /* parse command line options and populate QAPI @backend */
>>> void (*parse)(QemuOpts *opts, ChardevBackend *backend, Error **errp);
>>>
>>> - /* called after construction, open/starts the backend */
>>> + /*
>>> + * Called after construction, create and open/starts the backend,
>>
>> What to do mean by "create and open/starts"?
>> Maybe "create and start"?
>
> Yes, sounds good.
>
>>> + * mutual exclusive with .init. .connect must not be defined when
>>
>> mutually
>>
>>> + * .open is defined.
>>> + */
>>
>> Suggest to use @name to refer to a member name. We do that elsewhere,
>> and it's easier on the eyes than dots.
>>
>>> void (*open)(Chardev *chr, ChardevBackend *backend,
>>> bool *be_opened, Error **errp);
>>> + /*
>>> + * Called after construction, create the backend, mutual exclusive
>>
>> mutually
>>
>>> + * with .open, and must be accompanied by .connect.
>>
>> Is it okay to destroy after init() without connect()?
>> If yes, "must" is misleading.
>
> Hmm. "should" is OK then?
"Should be followed by connect()" would work.
Or something like "The backend still needs to be started with init()."
>>> + * Must set chr-filename.
>>
>> What's chr-filename?
>
> Type. That should be chr->filename. Or better @chr->filename ?
There is no member @chr. I figure it's CharBackend member @chr.
Perhaps "the CharBackend's chr->filename".
[...]
> Thanks for reviewing!
You're welcome!
next prev parent reply other threads:[~2025-10-15 7:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 15:26 [PATCH v3 0/7] chardev: postpone connect Vladimir Sementsov-Ogievskiy
2025-10-14 15:26 ` [PATCH v3 1/7] chardev/char-socket: simplify reconnect-ms handling Vladimir Sementsov-Ogievskiy
2025-10-14 15:26 ` [PATCH v3 2/7] chardev/char: split chardev_init_logfd() out of qemu_char_open() Vladimir Sementsov-Ogievskiy
2025-10-15 6:35 ` Markus Armbruster
2025-10-15 6:47 ` Vladimir Sementsov-Ogievskiy
2025-10-14 15:26 ` [PATCH v3 3/7] chardev/char: qemu_char_open(): add return value Vladimir Sementsov-Ogievskiy
2025-10-15 6:37 ` Markus Armbruster
2025-10-14 15:26 ` [PATCH v3 4/7] chardev/char: move filename and be_opened handling to qemu_char_open() Vladimir Sementsov-Ogievskiy
2025-10-14 15:26 ` [PATCH v3 5/7] chardev/char: introduce .init() + .connect() initialization interface Vladimir Sementsov-Ogievskiy
2025-10-15 6:50 ` Markus Armbruster
2025-10-15 6:58 ` Vladimir Sementsov-Ogievskiy
2025-10-15 7:49 ` Markus Armbruster [this message]
2025-10-14 15:26 ` [PATCH v3 6/7] chardev/char-socket: move to .init + .connect api Vladimir Sementsov-Ogievskiy
2025-10-14 15:26 ` [PATCH v3 7/7] chardev: introduce DEFINE_PROP_CHR_NO_CONNECT Vladimir Sementsov-Ogievskiy
2025-10-15 6:56 ` Markus Armbruster
2025-10-15 7:11 ` Vladimir Sementsov-Ogievskiy
2025-10-15 7:55 ` Markus Armbruster
2025-10-15 8:19 ` Vladimir Sementsov-Ogievskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87plaofvug.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=d-tatianin@yandex-team.ru \
--cc=eduardo@habkost.net \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=raphael@enfabrica.net \
--cc=vsementsov@yandex-team.ru \
--cc=yc-core@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).