qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/7] virtio-blk: use aliases instead of duplicat


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 4/7] virtio-blk: use aliases instead of duplicate qdev properties
Date: Thu, 22 May 2014 12:32:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Am 22.05.2014 12:24, schrieb Stefan Hajnoczi:
> On Thu, May 22, 2014 at 12:18 PM, Andreas Färber <address@hidden> wrote:
>> Am 22.05.2014 00:04, schrieb Paolo Bonzini:
>>> Il 21/05/2014 22:22, Stefan Hajnoczi ha scritto:
>>>> virtio-blk-pci, virtio-blk-s390, and virtio-blk-ccw all duplicate the
>>>> qdev properties of their VirtIOBlock child.  This approach does not work
>>>> well with string or pointer properties since we must be careful about
>>>> leaking or double-freeing them.
>>>>
>>>> Use the QOM alias property to forward property accesses to the
>>>> VirtIOBlock child.  This way no duplication is necessary.
>>>>
>>>> Remember to stop calling virtio_blk_set_conf() so that we don't clobber
>>>> the values already set on the VirtIOBlock instance.
>>>
>>> Which properties are _not_ being added?  This is probably needed for all
>>> other virtio devices so a generic solution would be nice.
>>
>> "type", "realized" and the child<> property for VirtIODevice come to
>> mind, possibly one or two more.
>>
>> If we follow a generic scheme, we could add an .instance_post_init hook
>> for VirtIOPCIProxy iterating over all properties and blacklisting some.
> 
> I think the trick is to alias all the qdev properties, not the QOM
> ones.  That way we get all the explicitly declared properties and none
> of the implicit ones.

I wouldn't oppose that, but you then need to iterate over parent classes
until you hit VirtioDeviceClass (or DeviceClass?), to avoid properties
falling through the cracks.

I just figured it easier and in line with your QMP patch to avoid
distinguishing them in new code. But a quick solution is more important
than futureproofness here, so I'll take or ack whatever works here.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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