Re: [PATCH 0/4] qemu-storage-daemon: QAPIfy --chardev the stupid way

From: Paolo Bonzini <pbonzini@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: marcandre.lureau@redhat.com,
	Eduardo Habkost <ehabkost@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH 0/4] qemu-storage-daemon: QAPIfy --chardev the stupid way
Date: Wed, 28 Oct 2020 17:01:24 +0100	[thread overview]
Message-ID: <e95c354e-64c6-b014-36fa-37a93bf32d1f@redhat.com> (raw)
In-Reply-To: <20201028153946.GC7355@merkur.fritz.box>

On 28/10/20 16:39, Kevin Wolf wrote:
>> I don't disagree with that, but it's a problem you have to solve anyway,
>> isn't it?  Once you figure out how to introspect QOM classes, that would
>> apply just as well to character devices.
> Yes, it's the problem I tried to address with my series, and Markus with
> this alternative series. We need to do this either way.

Right, I appreciate that QOMifying chardev would only be a solution if
QOM introspection gets into 6.0.  This is why I only brought it up
because neither of these series will be ready in time for 5.2.

So maybe QOMifying chardev wouldn't make it a non-problem; it would make
it someone else's (Eduardo's) problem.

> you need to know what these properties should look like

True that.  But I think the existing QAPI structures do help for that.

> If you don't wait for the QAPI work, you'll have solved the problem of
> having two separate ways to describe chardev options by making it three
> separate ways. Technically this might fulfill the condition of not
> having two separate ways, but it's not really what we had in mind. :-)

Actually four ways (-chardev, chardev-add, -object, object-add) but two
of them would be implemented by the same code and qsd would be able to
standardize on them.

Paolo