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 those, and said that we can apply all three. It's
> certainly better than reverting. That doesn't mean that keeping broken
> code would have been better than reverting.
Right, my preferred way would've been a) Peter C. noticing in the first
place or b) Peter C. supplying the one-line NAND fix that I had to write
myself after no one else managed to come up with a real fix. :(
> 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.
> But my request to "look at the actual code" was not related to
> contribution of patches. It referred to _all_ of QEMU device hierarchy.
> Your assertion that "qdev is dead" seems quite an exaggeration; having
> contributed quite a few patches to "kill" qdev-specific mechanisms in
> favor of generic ones, it seems very much alive to me.
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 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. ;)
So yes, we still have buses, but yet qdev is a thing of the past. That's
why I have always asked to use device_ rather than qdev_ in new qdev.c
code. Scott openly said he didn't realize we had switched to QOM because
as a device author he was still using qdev_create(), qdev_init() and
other APIs with qdev in their name - that's the battle I'm fighting:
getting qdev out of people's heads and stopping to think the old way
just because it's been like that for a long time.
However, based on Anthony's vision/dogma/whatever I do not consider it
worth to rename qdev_set_parent_bus() to device_set_parent_bus() iff
Anthony wants to get rid of buses. And in that case i wouldn't want to
replace qdev_create() with object_new() + qdev_set_parent_bus() since
that's replacing Satan with Lucifer. ;)
> Let's look at qdev. Ask ourselves what useful functionality of Device
> has nothing to do with devices. Ask ourselves where it clashes with the
> design of Object, and which of the two is better. Make a design that is
> consistent with what we need, not with a generic 2-year old vision that
> sometimes borders on dogma. Then we can write code.
>
> This is all totally unrelated from which interesting relationships are
> useful to extract and visualize from the QOM tree---and my point there
> is that both parent-child ("qom-tree") and controller-controlled ("info
> qtree") are useful relationships.
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 intend to post patches offering new, alternative displays of the
composition tree (info qom-composition) since apparently there is a new
demand for HMP (I was actually under the impression HMP was deprecated
by QMP ever since we started added QMP-only commands like qom-* and
cpu-add, so this script would've been all to make use of the existing
QMP interface to get property values printed!) and I have been
considering a cpu-add like HMP wrapper around qom-list for property
discovery. But I do not see why I should turn "info qtree" into
something that's incompatible with its very idea and ignores the new
composition. Container objects and SoC objects are examples beyond
non-x86 CPU and NAND that do not fit into "info qtree". We don't
strictly needed buses for new devices any more, we'd then just need code
for -device and device_add to do the Right Thing. And this is affecting
actual patches such as s390x vCPU hot-plug and memory hot-add where we
have been discussing whether and in which form we should introduce an
interim bus to please legacy code and/or how we can make that work
longer-term with the QOM composition model.
Please define what you consider the interesting part of info qtree wrt
controller-controlled you would like to see. My problem with info qtree
is that it's trying to show the whole world in terms of recursive buses,
which is no longer applicable to QOM. Do you want to see all properties?
Then this script here does that. Do you want to see PCI free/occupied
slots on the PHB? Then a composition tree can show that. Do you want to
see which buses are available for bus=? Then a flat list of buses - with
or without children - would do, no bus tree needed, or the composition
tree shows them as children where they could be highlighted as proposed.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
