qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] QEMU Object Model


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC] QEMU Object Model
Date: Fri, 22 Jul 2011 15:15:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11

Am 22.07.2011 14:40, schrieb Anthony Liguori:
> On 07/22/2011 02:46 AM, Kevin Wolf wrote:
>> Am 21.07.2011 18:32, schrieb Anthony Liguori:
>>> Just as we're now realizing that we need to do dramatic things in the
>>> block layer to make -blockdev work, I'm sure we're going to realize that
>>> we want to do PCI hotplug of virtio-serial and therefore we need to do
>>> dynamic creation/destruction of character devices.
>>
>> Just to have it said: -blockdev isn't the reason for doing something
>> like this. The reason is that you want it. (Not saying anything about
>> whether it is a good or a bad thing to want)
>>
>> What -blockdev really needs is an additional parameter to bdrv_open that
>> carries the options. Could be as simple as a QDict, though that might
>> not align well with your QAPI which wants everything to be C. But in any
>> case, generalising the qdev properties mechanism to be usable in other
>> contexts should be enough for anything.
> 
> That's what QOM is.  qdev generalized.

Hm, yes, quite possible.

Then maybe it's just its usage that I'm not happy with. You're turning
the block layer upside down to change BlockDriverStates and BDRV*State
to fit this API, which at the first sight looks pretty invasive. I was
thinking of an object not for the whole BDS, but just for the same
purpose as the QDict would have been used, that is something that can be
passed to bdrv_open.

On the other hand, it's really hard to quickly see in your git tree what
changes QOM really means. Real patches to the existing code would be
much more useful than an additional modified copy of the file.

Kevin



reply via email to

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