qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v2 0/9] qom: Make object_get_class()/*_GET_CLASS r


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC v2 0/9] qom: Make object_get_class()/*_GET_CLASS return const pointers
Date: Thu, 30 Mar 2017 10:59:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0


On 29/03/2017 21:41, Eduardo Habkost wrote:
> QOM has a data model where class struct data is static: class
> structs are initialized at class_init, and never changed again.

Isn't that just the way class data is being used?  There's no reason for
class data to be static.  It happens to be that way because our
hierarchies are pretty shallow and global static variables are used
instead of class data.  But it doesn't _have_ to be like that.

That said, the QUALIFIED_CAST concept is very interesting and I'd even
extend it to OBJECT_CHECK, object_dynamic_cast and
object_dynamic_cast_assert.  I'm just not sure about returning const
from object_get_class()/*_GET_CLASS, which ironically is the thing that
prompted you to write the series. :)

Paolo

> ...except for a few rare cases where class data is changed
> outside class_init. Those cases are:
> 
>   qbus_realize(), code added by:
>   commit 61de36761b565a4138d8ad7ec75489ab28fe84b6
>   Date:   Thu Feb 6 16:08:15 2014 +0100
>       qdev: Keep global allocation counter per bus
> 
>   mips_jazz_init(), code added by:
>   commit 54e755588cf1e90f0b1460c4e8e6b6a54b6d3a32
>   Date:   Mon Nov 4 23:26:17 2013 +0100
>       mips jazz: do not raise data bus exception when accessing invalid 
> addresses
> 
>   xen_set_dynamic_sysbus(), code added by:
>   commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894
>   Date:   Tue Nov 22 07:10:58 2016 +0100
>       xen: create qdev for each backend device
> 
>   s390_cpu_realizefn(), code added by:
>   commit c6644fc88bed1176f67b4b7a9df691bcf25c0c5b
>   Date:   Fri Mar 4 12:34:31 2016 -0500
>       s390x/cpu: Get rid of side effects when creating a vcpu



reply via email to

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