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

[Halil Pasic <pasic@linux.vnet.ibm.com>]

On 12/08/2017 12:42 PM, Cornelia Huck wrote:
[..]
>>>>>> In general, I kind of agree with Halil. Unless somewhere in QEMU it is
>>>>>> documented that the QOM tree is not guaranteed to be stable for
>>>>>> exploiters, I'd consider is part of the API. libvirt does use at least
>>>>>> some hardcoded paths, most of the time for CPUs in /machine/unattached,
>>>>>> so if that relation would change, things break. However, there is also
>>>>>> code to traverse the QOM tree recursively and find a path for a given
>>>>>> type(?) name. If this is the preferred way, we probably should change
>>>>>> this in libvirt to be safe.    
>>>>>
>>>>> OK, with that in mind and as we're now adding a property to check on
>>>>> the css bridge, I vote for including patch 1 now (having a fixed
>>>>> location under /machine looks saner that having to
>>>>> check /machine/unattached/device[<n>], which might not be stable).
>>>>>
>>>>> Patch 2 needs more discussion, as I'm not sure whether what I'm doing
>>>>> is the correct way to go about this (and other machines are in the same
>>>>> situation). Not sure whether it is worth trying to attach the zpci
>>>>> devices somewhere.
>>>>>     
>>>>
>>>> I think, if it's kind of API, then fixing sooner is better than fixing
>>>> later.
>>>>
>>>> I also agree that patch 1 should be higher priority.
>>>>
>>>> Before we do patch 1 I would like having agreed and documented whether
>>>> this is API or not.
>>>>
>>>> If we decide it's an API, I think we should consider deprecating
>>>> the current interface, but keep it working for two releases or
>>>> so. I think nothing speaks against introducing a link form unattached
>>>> in patch 1 (but I have not tried yet).  
>>>
>>> No, just no. That's completely overengineered.
>>>   
>>
>> Which part is totally overengineered? Having it clear what is API and
>> what not? Having this documented? Or caring about our deprecation
>> policy (if it's API)?
>>
> 
> You're building a monster to fix a non-existing problem. I will not go
> down that rabbit hole any further, and just apply patch 1.
> 

I'm not building anything. I've basically just asked a simple question:
Are  paths in the qom composition tree external API or not (and if not,
what is the canonical way to accomplish certain things)? Then I though
out loud about the branches we can take based on the answer.

Based on the answers I got it seems I'm not particularly good at asking
questions. Sorry about that.

Halil