Re: [qemu-s390x] [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices

[Halil Pasic]

On 12/04/2017 10:22 AM, Cornelia Huck wrote:
> On Fri, 1 Dec 2017 15:41:21 +0100
> Halil Pasic <address@hidden> wrote:
> 
>> On 11/28/2017 04:21 PM, Halil Pasic wrote:
>> [..]
>>>>> Otherwise at first glance both patches seem sane.  
>>>>
>>>> Can I count this as an ack, or do you plan to do more review?
>>>>  
>>>
>>> Yes I was planning to give it another look. And I do already
>>> have questions. Isn't the QOM composition tree API? I mean
>>> let's assume the QMP commands working on this tree are not completely
>>> useless. How is client code (management software) supposed to work,
>>> assumed it can rely on paths of e.g. properties being stable. Just
>>> imagine we had this default-cssid property (for the sake of the
>>> argument, not like we want it) on the css bridge.  
>>
>> Ping! I would like to get this clarified before proceeding with reviewing
>> this series.
> 
> [It might be helpful to not drop cc:s.]
> 

Sorry. Wrong button.

> I don't think we really want a static tree. As long as the devices are
> locateable, it should be fine.
> 

What do you mean by locateable in particular?

Let's say I'm management software guy who want's to access a certain
property of a certain device. For that I'm supposed to use qom-get. Now
qom-get takes a path as input argument (absolute or relative). The question
is, how I'm supposed to figure out this path as management software developer?
In other words what is the algorithm?

One naive approach would be, to assume that the path is stable between
releases. So I have to figure it out when I'm implementing the stuff,
and then it keeps working ever after. I read your answer as this naive
approach is wrong.

(BTW I find static also confusing in this context.)

[..]