qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.vnet.ibm.com>
Cc: borntraeger@de.ibm.com, qemu-s390x@nongnu.org,
	pmorel@linux.vnet.ibm.com, Bjoern Walk <bwalk@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices
Date: Fri, 8 Dec 2017 12:42:45 +0100	[thread overview]
Message-ID: <20171208124245.53eb5db6.cohuck@redhat.com> (raw)
In-Reply-To: <95059339-fac0-ee39-2e68-4ff5bc793893@linux.vnet.ibm.com>

On Thu, 7 Dec 2017 18:15:57 +0100
Halil Pasic <pasic@linux.vnet.ibm.com> wrote:

> 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 <bwalk@linux.vnet.ibm.com>
> >>>>
> >>>> 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)?
> 

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.

  reply	other threads:[~2017-12-08 11:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-28 13:46 [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices Cornelia Huck
2017-11-28 13:46 ` [Qemu-devel] [PATCH RFC 1/2] s390x/css: attach css bridge Cornelia Huck
2017-11-28 14:02   ` Christian Borntraeger
2017-12-08 11:43   ` Cornelia Huck
2017-11-28 13:46 ` [Qemu-devel] [PATCH RFC 2/2] s390x: attach autogenerated nics Cornelia Huck
2017-12-04 11:17   ` [Qemu-devel] [qemu-s390x] " Christian Borntraeger
2017-12-04 16:40     ` Cornelia Huck
2017-12-04 17:33       ` Halil Pasic
2017-12-04 17:51         ` Cornelia Huck
2017-11-28 14:17 ` [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices Halil Pasic
2017-11-28 14:27   ` Cornelia Huck
2017-11-28 15:21     ` Halil Pasic
2017-12-01 14:41       ` Halil Pasic
2017-12-04  9:22         ` Cornelia Huck
2017-12-04 14:47           ` Halil Pasic
2017-12-04 16:51             ` Cornelia Huck
2017-12-04 11:47 ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2017-12-05  8:59 ` [Qemu-devel] " Bjoern Walk
2017-12-07 16:34   ` Cornelia Huck
2017-12-07 17:01     ` Halil Pasic
2017-12-07 17:06       ` Cornelia Huck
2017-12-07 17:15         ` Halil Pasic
2017-12-08 11:42           ` Cornelia Huck [this message]
2017-12-08 12:14             ` Halil Pasic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171208124245.53eb5db6.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=bwalk@linux.vnet.ibm.com \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=pmorel@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).