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

From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@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 16:39:46 +0100	[thread overview]
Message-ID: <20201028153946.GC7355@merkur.fritz.box> (raw)
In-Reply-To: <8103b738-aff7-fc50-67ac-59fd1262c06a@redhat.com>

Am 28.10.2020 um 16:09 hat Paolo Bonzini geschrieben:
> On 28/10/20 15:59, Kevin Wolf wrote:
> >> Making more use of QOM will make this a non-problem.  You'll just use
> >> object-add and -object and, when you figure out the QOM schema, it will
> >> just work.
> >
> > Yes, but figuring out the QOM schema (or rather, what the interface
> > represented by the schema should look like) is the hard part.
> 
> 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.

> On the other hand, creating character devices with -object does solve
> another problem, namely the distinction between "early" and "late"
> objects in vl.c, in a way that QAPIfied -chardev doesn't solve.

Right. Both are solving different problems, and solving one won't
automatically make the other a non-problem as you suggested above.

I just suggested leaving QOM for later because two people making big
changes on the same subsystem is going to be painful for at least one of
them, and because for adding QOM properties, you need to know what these
properties should look like (unless you want to change them again
later).

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. :-)

Kevin