[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Halil Pasic
Subject: Re: [qemu-s390x] [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices
Date: Thu, 7 Dec 2017 18:15:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 12/07/2017 06:06 PM, Cornelia Huck wrote:
> On Thu, 7 Dec 2017 18:01:46 +0100
>>>> Regarding the discussion about whether the QOM tree is API and what
>>>> exploiters like libvirt should do, Halil asked me to chip in.
>>>> This patch is fine from libvirt perspective. I did a quick smoke test
>>>> and you can have a
>>>>     Tested-by: Bjoern Walk <address@hidden>
>>>> for what it's worth.  
>>> Thanks for checking.
>>>> 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)?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]