qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [PATCH 0/4] qemu-storage-daemon: QAPIfy --chardev the stupid way
Date: Wed, 28 Oct 2020 16:39:46 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]