Re: [Qemu-devel] [PATCH] scripts: Add qom-tree script as modern equivalent of info qtree

[Paolo Bonzini]

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 broke things.

Ok, so far so good.  Though I think remembering people about the 
Damocles sword of reverting the patch is fair after 1 month.

> Negative, all the device registration, structs, etc. of qdev apart from
> the actual devices' *State is gone, no longer exists. See Anthony's
> large commits in Git history if you don't believe me. You do know better
> than what you are saying here.

I guess there's a difference in terminology.

You're saying qdev is dead.  I'm saying it is now implemented on top of 
QOM.  All the "meta" stuff in qdev is dead indeed.  But the _concepts_ 
are alive and still being used.  Part of it is because no one bothered 
to fix that, but part of it is because there was nothing to fix. :)

> I certainly agree that there were a
> number of oversights and bugs the two of us and others have been fixing.
> So you could argue that QOM was applied to fast with insufficient
> testing and thinking-through - but also in this case I will rather fix
> the fallout than reverting QOM. ;)

Sure.  At the same time, let's not treat QOM and the QOMified qdev as 
crystallized things.

So, Anthony's plan said "no more buses".  The question is also, will 
Anthony ultimately get rid of buses?  I honestly doubt that, and that's 
unrelated to the decrease of his involvement in the last few months.

This is what I referred to as "design by prophet".  It makes no sense to 
judge people's contributors on the basis of a 2-year old plan whose 
execution so far encountered more than a few hurdles.

Let people come up with their own design, and let their design and code 
speak.

FWIW, qdev also had dynamic properties in the beginning; it was Gerd who 
converted them to static.  Why shouldn't the same thing happen for QOM, 
if the code shows that it is an improvement?  Of course, these 
hypothetical QOM static properties need not (should not, in all 
likelihood) be a copycat imitation of what we have in Device.

> I'm not arguing against that. I have rather been telling you that trying
> to *shoehorn* QOM objects into "info qtree" cannot work well.
>
> The claim has been that info qtree *should* include all devices (nand in
> particular) and that claim I strongly dispute. And I reject you giving
> me instructions for how I should implement "info qtree" for you in your
> opinion.

I didn't say you *should* do that.  I said it's *possible* to do that. 
Is it good or bad?  Honestly, I cannot say because there are so few 
busless devices that the current "info qtree" is pretty good as it 
already is.  I don't care enough, for now.  Later, perhaps, I will.

> I intend to post patches offering new, alternative displays of the
> composition tree (info qom-composition) since apparently there is a new
> demand for HMP

Yes, that's useful!

I'm snipping the rest of the email because right now I cannot put enough 
thought into it.

Paolo