Andreas Färber writes:
> Am 07.02.2014 14:06, schrieb Paolo Bonzini:
>> Il 07/02/2014 13:44, Andreas Färber ha scritto:
>>> Am 07.02.2014 12:21, schrieb Paolo Bonzini:
Let's stop talking about theory and let's look at the actual ccode,
please.
>>>
>>> I have posted actual patches, you h
Il 07/02/2014 14:48, Andreas Färber ha scritto:
And let me repeat that
*reverting a broken patch should always be one of the alternatives*.
Yes. But it has never been *mandatory* to revert things first before
fixing them. We usually apply incremental fixes referencing the commit
hash that brok
Am 07.02.2014 14:06, schrieb Paolo Bonzini:
> Il 07/02/2014 13:44, Andreas Färber ha scritto:
>> Am 07.02.2014 12:21, schrieb Paolo Bonzini:
>>> Let's stop talking about theory and let's look at the actual ccode,
>>> please.
>>
>> I have posted actual patches, you haven't.
>
> I have reviewed thos
Il 07/02/2014 13:49, Andreas Färber ha scritto:
qdev is a framework from Paul Brook with a bus-tree-oriented graph.
QOM by comparison uses an arbitrary composition tree of child<> nodes.
qdev as such no longer exists since late 2011 / early 2012.
Let me be blunt: to me, this is a huge, huge de
Il 07/02/2014 13:44, Andreas Färber ha scritto:
Am 07.02.2014 12:21, schrieb Paolo Bonzini:
Let's stop talking about theory and let's look at the actual ccode, please.
I have posted actual patches, you haven't.
I have reviewed those, and said that we can apply all three. It's
certainly bet
Am 07.02.2014 12:21, schrieb Paolo Bonzini:
> Il 07/02/2014 12:09, Andreas Färber ha scritto:
>>> No matter how much I like QOM (I do), I would rather say that the all
>>> QOM grand plan has been "inconclusive". 99% in-tree uses of QOM are
>>> just a glorified qdev, buses and all. You shouldn't b
Am 07.02.2014 12:21, schrieb Paolo Bonzini:
> Let's stop talking about theory and let's look at the actual ccode, please.
I have posted actual patches, you haven't. I even asked you to myself.
And there's no point continuing discussions about reverts here when
there are actual solutions - by me -
Il 07/02/2014 12:09, Andreas Färber ha scritto:
No matter how much I like QOM (I do), I would rather say that the all
QOM grand plan has been "inconclusive". 99% in-tree uses of QOM are
just a glorified qdev, buses and all. You shouldn't be surprised if
people still care about the "legacy" qdev
Il 07/02/2014 12:00, Andreas Färber ha scritto:
Am 07.02.2014 11:41, schrieb Paolo Bonzini:
Il 05/02/2014 19:08, Andreas Färber ha scritto:
http://wiki.qemu.org/Features/QOM#TODO
Anthony wants buses to go away completely. So that seems a legacy
concept to me even though they do not seem to be
Am 07.02.2014 08:13, schrieb Paolo Bonzini:
> Il 05/02/2014 19:01, Andreas Färber ha scritto:
>> Am 05.02.2014 18:55, schrieb Paolo Bonzini:
>>> Il 05/02/2014 18:51, Andreas Färber ha scritto:
>> So, even though I think this script is a very welcome addition, I
> don't
>> think it helps
Am 07.02.2014 11:41, schrieb Paolo Bonzini:
> Il 05/02/2014 19:08, Andreas Färber ha scritto:
>> http://wiki.qemu.org/Features/QOM#TODO
>>
>> Anthony wants buses to go away completely. So that seems a legacy
>> concept to me even though they do not seem to be gone tomorrow.
>
> The way I read that
Il 05/02/2014 19:08, Andreas Färber ha scritto:
http://wiki.qemu.org/Features/QOM#TODO
Anthony wants buses to go away completely. So that seems a legacy
concept to me even though they do not seem to be gone tomorrow.
The way I read that, buses would be replaced by controller devices.
This is
Il 05/02/2014 19:01, Andreas Färber ha scritto:
Am 05.02.2014 18:55, schrieb Paolo Bonzini:
Il 05/02/2014 18:51, Andreas Färber ha scritto:
So, even though I think this script is a very welcome addition, I
don't
think it helps settling the question of what to do with "info qtree".
IMO there's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 05.02.2014 19:24, schrieb Eric Blake:
> On 02/05/2014 10:35 AM, Andreas Färber wrote:
>> Functionally it is a recursive qom-list with qom-get per
>> non-child<> property. Some failures needed to be handled, such as
>> trying to read a pointer proper
On 02/05/2014 10:35 AM, Andreas Färber wrote:
> Functionally it is a recursive qom-list with qom-get per non-child<>
> property. Some failures needed to be handled, such as trying to read a
> pointer property, which is not representable in QMP. Those print a
> literal "".
>
> Signed-off-by: Andrea
Functionally it is a recursive qom-list with qom-get per non-child<>
property. Some failures needed to be handled, such as trying to read a
pointer property, which is not representable in QMP. Those print a
literal "".
Signed-off-by: Andreas Färber
---
scripts/qmp/qom-tree | 70 +
Am 05.02.2014 18:58, schrieb Paolo Bonzini:
> Il 05/02/2014 18:56, Andreas Färber ha scritto:
>> I don't think it's a modern equivalent of anything. The two are
just
>> different.
>> It is quite obviously the equivalent in that it dumps the values of all
>> properties like info qtre
Am 05.02.2014 18:55, schrieb Paolo Bonzini:
> Il 05/02/2014 18:51, Andreas Färber ha scritto:
>>> > So, even though I think this script is a very welcome addition, I
>>> don't
>>> > think it helps settling the question of what to do with "info qtree".
>>> > IMO there's no good reason to exclude bus
Il 05/02/2014 18:35, Andreas Färber ha scritto:
Functionally it is a recursive qom-list with qom-get per non-child<>
property. Some failures needed to be handled, such as trying to read a
pointer property, which is not representable in QMP. Those print a
literal "".
Signed-off-by: Andreas Färber
Il 05/02/2014 18:51, Andreas Färber ha scritto:
> So, even though I think this script is a very welcome addition, I don't
> think it helps settling the question of what to do with "info qtree".
> IMO there's no good reason to exclude busless devices from "info qtree",
> and it's a bug (of course
Am 05.02.2014 18:48, schrieb Paolo Bonzini:
> Il 05/02/2014 18:35, Andreas Färber ha scritto:
>> Functionally it is a recursive qom-list with qom-get per non-child<>
>> property. Some failures needed to be handled, such as trying to read a
>> pointer property, which is not representable in QMP. Tho
Il 05/02/2014 18:56, Andreas Färber ha scritto:
>> I don't think it's a modern equivalent of anything. The two are just
>> different.
It is quite obviously the equivalent in that it dumps the values of all
properties like info qtree does for static properties only of
qbus-attached devices only.
Am 05.02.2014 18:51, schrieb Andreas Färber:
> Am 05.02.2014 18:48, schrieb Paolo Bonzini:
>> Il 05/02/2014 18:35, Andreas Färber ha scritto:
>>> Functionally it is a recursive qom-list with qom-get per non-child<>
>>> property. Some failures needed to be handled, such as trying to read a
>>> point
23 matches
Mail list logo
