On 30/07/20 14:36, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 30/07/20 12:03, Markus Armbruster wrote:
>>> qdev C layer:
>>>
>>> frob->prop = 42;
>>>
>>> Least cognitive load.
>>>
>>> QOM has no C layer.
>>
>> Not really, a QOM object is totally free to do frob->prop = 42. And
Paolo Bonzini writes:
> On 30/07/20 12:03, Markus Armbruster wrote:
>> qdev C layer:
>>
>> frob->prop = 42;
>>
>> Least cognitive load.
>>
>> QOM has no C layer.
>
> Not really, a QOM object is totally free to do frob->prop = 42. And
> just like we didn't do that outside device implementa
On 30/07/20 12:03, Markus Armbruster wrote:
> qdev C layer:
>
> frob->prop = 42;
>
> Least cognitive load.
>
> QOM has no C layer.
Not really, a QOM object is totally free to do frob->prop = 42. And
just like we didn't do that outside device implementation in qdev as our
tithe to the Churc
Paolo Bonzini writes:
> On 29/07/20 15:18, Markus Armbruster wrote:
>>> Even code riddled by backwards-compatibility special cases, such as
>>> -accel and -machine, can share code between themselves and -object to
>>> some extent; this is thanks to functions such as object_property_parse,
>>> who
On 29/07/20 18:08, Eduardo Habkost wrote:
The main thing we get from it is that the QOM paths treat children and
links the same, and links are properties. To be honest it's not a
feature that is very much developed, so perhaps we can remove it but we
need to evaluate the impact
On Wed, Jul 29, 2020 at 06:01:31PM +0200, Paolo Bonzini wrote:
> On 29/07/20 16:32, Eduardo Habkost wrote:
> > On Wed, Jul 29, 2020 at 11:54:35AM +0200, Paolo Bonzini wrote:
> >> On 29/07/20 00:47, Eduardo Habkost wrote:
> > [...]
> >>> Do we really need need QOM children to be accessible using the
On 29/07/20 15:18, Markus Armbruster wrote:
>> Even code riddled by backwards-compatibility special cases, such as
>> -accel and -machine, can share code between themselves and -object to
>> some extent; this is thanks to functions such as object_property_parse,
>> whose parsing is deferred to visi
On 29/07/20 16:32, Eduardo Habkost wrote:
> On Wed, Jul 29, 2020 at 11:54:35AM +0200, Paolo Bonzini wrote:
>> On 29/07/20 00:47, Eduardo Habkost wrote:
> [...]
>>> Do we really need need QOM children to be accessible using the QOM
>>> property API?
>>>
>>> Using the same code for both user-configur
On Wed, Jul 29, 2020 at 11:54:35AM +0200, Paolo Bonzini wrote:
> On 29/07/20 00:47, Eduardo Habkost wrote:
[...]
> > Do we really need need QOM children to be accessible using the QOM
> > property API?
> >
> > Using the same code for both user-configurable properties and for
> > the list of childr
Paolo Bonzini writes:
> On 29/07/20 00:47, Eduardo Habkost wrote:
>> On Tue, Jul 28, 2020 at 07:38:27PM +0200, Paolo Bonzini wrote:
>>> On 28/07/20 09:19, Markus Armbruster wrote:
> the composition tree generally mirrors things that are born and die
> at the same time, and creating childr
On 29/07/20 00:47, Eduardo Habkost wrote:
> On Tue, Jul 28, 2020 at 07:38:27PM +0200, Paolo Bonzini wrote:
>> On 28/07/20 09:19, Markus Armbruster wrote:
the composition tree generally mirrors things that are born and die
at the same time, and creating children is generally reserved to th
Paolo Bonzini writes:
> On 28/07/20 09:19, Markus Armbruster wrote:
>>> the composition tree generally mirrors things that are born and die
>>> at the same time, and creating children is generally reserved to the
>>> object itself.
>>
>> Yes. Notable exceptions: containers /machine/peripheral,
>
On Tue, Jul 28, 2020 at 07:38:27PM +0200, Paolo Bonzini wrote:
> On 28/07/20 09:19, Markus Armbruster wrote:
> >> the composition tree generally mirrors things that are born and die
> >> at the same time, and creating children is generally reserved to the
> >> object itself.
> >
> > Yes. Notable e
On 28/07/20 09:19, Markus Armbruster wrote:
>> the composition tree generally mirrors things that are born and die
>> at the same time, and creating children is generally reserved to the
>> object itself.
>
> Yes. Notable exceptions: containers /machine/peripheral,
> /machine/peripheral-anon, /mac
Paolo Bonzini writes:
> On 21/07/20 08:00, Markus Armbruster wrote:
>>> They are already mirrored as links, and guess what's the link
>>> name: "child[...]".
>> You're right, except for the link name: it's parent_bus.
>
> There's links in both directions.
>
>> So the qtree is actually embedded in
On 21/07/20 08:00, Markus Armbruster wrote:
>> They are already mirrored as links, and guess what's the link
>> name: "child[...]".
> You're right, except for the link name: it's parent_bus.
There's links in both directions.
> So the qtree is actually embedded in the QOM graph: it's the device an
Eduardo Habkost writes:
> On Mon, Jul 20, 2020 at 09:38:24AM +0200, Markus Armbruster wrote:
>> Eduardo Habkost writes:
>>
>> > On Fri, Jul 17, 2020 at 07:10:57AM +0200, Markus Armbruster wrote:
>> >> Eduardo Habkost writes:
>> >>
>> >> > I'd also note that the use of "parent" in the code is
On Mon, Jul 20, 2020 at 09:38:24AM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > On Fri, Jul 17, 2020 at 07:10:57AM +0200, Markus Armbruster wrote:
> >> Eduardo Habkost writes:
> >>
> >> > I'd also note that the use of "parent" in the code is also
> >> > ambiguous. It can mea
Peter Maydell writes:
> On Fri, 17 Jul 2020 at 17:32, Daniel P. Berrangé wrote:
>> Personally I've not seen a problem with the term "parent" in
>> this scenario. The class inheritance metaphor maps reasonably
>> clearly to a parent/child metaphor.
>
> It's not bad in itself; it's just that it me
Eduardo Habkost writes:
> On Fri, Jul 17, 2020 at 07:10:57AM +0200, Markus Armbruster wrote:
>> Eduardo Habkost writes:
>>
>> > I'd also note that the use of "parent" in the code is also
>> > ambiguous. It can mean:
>> >
>> > * QOM parent type, i.e. TypeInfo.parent. Related fields:
>> > * p
On Fri, 17 Jul 2020 at 17:32, Daniel P. Berrangé wrote:
> Personally I've not seen a problem with the term "parent" in
> this scenario. The class inheritance metaphor maps reasonably
> clearly to a parent/child metaphor.
It's not bad in itself; it's just that it means almost all
of our objects ar
On Fri, Jul 17, 2020 at 12:23:12PM -0400, Eduardo Habkost wrote:
> On Fri, Jul 17, 2020 at 07:10:57AM +0200, Markus Armbruster wrote:
> > Eduardo Habkost writes:
> >
> > > I'd also note that the use of "parent" in the code is also
> > > ambiguous. It can mean:
> > >
> > > * QOM parent type, i.e.
On Fri, Jul 17, 2020 at 07:10:57AM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > I'd also note that the use of "parent" in the code is also
> > ambiguous. It can mean:
> >
> > * QOM parent type, i.e. TypeInfo.parent. Related fields:
> > * parent_class members of class struct
Eduardo Habkost writes:
> I'd also note that the use of "parent" in the code is also
> ambiguous. It can mean:
>
> * QOM parent type, i.e. TypeInfo.parent. Related fields:
> * parent_class members of class structs
> * parent_obj members of object structs
I hate the use of "parent" and "chi
On Wed, Jul 15, 2020 at 04:37:18PM +0200, Markus Armbruster wrote:
> Pratik Parvati writes:
>
> > Hi Markus and Philippe,
> >
> > Thanks for your reply. Now I am pretty clear about Qdev and sysbus helper
> > function.
> >
> > Can you please explain to me in brief on buses and device hierarchies (
Pratik Parvati writes:
> Hi Markus and Philippe,
>
> Thanks for your reply. Now I am pretty clear about Qdev and sysbus helper
> function.
>
> Can you please explain to me in brief on buses and device hierarchies (i.e.
> BusState and DeviceState) and how they are related to each other? As I can
>
On Wed, 15 Jul 2020 at 14:59, Pratik Parvati wrote:
> Can you please explain to me in brief on buses and device hierarchies (i.e.
> BusState and DeviceState) and how they are related to each other? As I can
> see, the DeviceState class inherits the BusState
>
> struct DeviceState {
> /*< pri
Hi Markus and Philippe,
Thanks for your reply. Now I am pretty clear about Qdev and sysbus helper
function.
Can you please explain to me in brief on buses and device hierarchies (i.e.
BusState and DeviceState) and how they are related to each other? As I can
see, the DeviceState class inherits th
Philippe Mathieu-Daudé writes:
> Hi Pratik,
>
> On 7/14/20 6:17 PM, Pratik Parvati wrote:
>> Here is a brief context that might help you.
>> I am referring hw/arm/versatilepb.c
>>
>> The ARM PrimeCell UART (PL011) device created as follows
>>
>> dev = qdev_create(NULL, "pl011");
>> s =
Hi Pratik,
On 7/14/20 6:17 PM, Pratik Parvati wrote:
> Here is a brief context that might help you.
> I am referring hw/arm/versatilepb.c
>
> The ARM PrimeCell UART (PL011) device created as follows
>
> |dev = qdev_create(NULL, "pl011"); s = SYS_BUS_DEVICE(dev);
> qdev_prop_set_chr(dev, "chardev
Hi Support team,
Can someone please guide me to understand the difference between
*sysbus_create_simple
*and *qdev_create*?.
I understand that these two methods are used to create a new device. But,
when to use these functions is not clear to me.
Regards,
Pratik
Here is a brief context that might help you.
I am referring hw/arm/versatilepb.c
The ARM PrimeCell UART (PL011) device created as follows
dev = qdev_create(NULL, "pl011");
s = SYS_BUS_DEVICE(dev);
qdev_prop_set_chr(dev, "chardev", chr);
qdev_init_nofail(dev);
sysbus_mmio_map(s
32 matches
Mail list logo
