From: David Gibson <david@gibson.dropbear.id.au>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Greg Kurz <groug@kaod.org>,
bharata@linux.vnet.ibm.com, sursingh@redhat.com,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/5] spapr: Add DRC release method
Date: Wed, 21 Jun 2017 16:18:17 +0800 [thread overview]
Message-ID: <20170621081817.GE12089@umbus> (raw)
In-Reply-To: <149798664805.10485.16662705281385907661@loki>
[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]
On Tue, Jun 20, 2017 at 02:24:08PM -0500, Michael Roth wrote:
> Quoting Greg Kurz (2017-06-20 11:51:45)
> > On Tue, 20 Jun 2017 09:53:30 +0800
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > At the moment, spapr_drc_release() has an ugly switch on the DRC type to
> > > call the right, device-specific release function. This cleans it up by
> > > doing that via a proper QOM method.
> > >
> > > It's still arguably an abstraction violation for the DRC code to call into
> > > the specific device code, but one mess at a time.
> > >
> >
> > Maybe a second step would be to move DRC subclasses to spapr.c (CPU, LMB) and
> > spapr_pci.c (PCI) ? This would allow each device-specific release function to
> > have local scope at least.
I was already thinking of doing that in a future patch :)
> I kind of prefer the proposed approach of registering a callback
> function via drc_new(). This would make it easier to implement
> unit tests without needing to rely on stub functions, and keeps the
> type-specific handling constrained to matters relating to the DRC
> itself and not the resources associated with them.
True. We went from the callback to this ugly switch when we made the
DRCs migratable (well, sort of, except for the many remaining
migration problems these cleanups are addressing amongst other
things). But moving the callback registration from attach time to new
time would do just as well. Well I'll think about it and do one or
the other in future.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2017-06-21 8:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 1:53 [Qemu-devel] [PATCH 0/5] spapr: DRC cleanups (part V) David Gibson
2017-06-20 1:53 ` [Qemu-devel] [PATCH 1/5] spapr: Leave DR-indicator management to the guest David Gibson
2017-06-20 16:05 ` [Qemu-devel] [Qemu-ppc] " Laurent Vivier
2017-06-20 16:12 ` [Qemu-devel] " Greg Kurz
2017-06-20 1:53 ` [Qemu-devel] [PATCH 2/5] spapr: Uniform DRC reset paths David Gibson
2017-06-20 16:32 ` Greg Kurz
2017-06-21 8:15 ` David Gibson
2017-06-20 19:12 ` [Qemu-devel] [Qemu-ppc] " Laurent Vivier
2017-06-20 1:53 ` [Qemu-devel] [PATCH 3/5] spapr: Add DRC release method David Gibson
2017-06-20 16:51 ` Greg Kurz
2017-06-20 19:24 ` Michael Roth
2017-06-21 8:18 ` David Gibson [this message]
2017-06-21 9:23 ` Greg Kurz
2017-06-20 19:14 ` [Qemu-devel] [Qemu-ppc] " Laurent Vivier
2017-06-20 1:53 ` [Qemu-devel] [PATCH 4/5] spapr: Remove unnecessary differences between hotplug and coldplug paths David Gibson
2017-06-20 19:16 ` [Qemu-devel] [Qemu-ppc] " Laurent Vivier
2017-06-21 9:38 ` [Qemu-devel] " Greg Kurz
2017-06-20 1:53 ` [Qemu-devel] [PATCH 5/5] spapr: Use unplug_request for PCI hot unplug David Gibson
2017-06-20 19:18 ` [Qemu-devel] [Qemu-ppc] " Laurent Vivier
2017-06-21 9:50 ` [Qemu-devel] " Greg Kurz
2017-07-03 6:35 ` David Gibson
2017-07-03 6:35 ` [Qemu-devel] [PATCH 0/5] spapr: DRC cleanups (part V) David Gibson
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=20170621081817.GE12089@umbus \
--to=david@gibson.dropbear.id.au \
--cc=bharata@linux.vnet.ibm.com \
--cc=groug@kaod.org \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=sursingh@redhat.com \
/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).