From: "Michael S. Tsirkin" <mst@redhat.com>
To: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: skandasa@cisco.com, etmartin@cisco.com, qemu-devel@nongnu.org,
wexu2@cisco.com
Subject: [Qemu-devel] Re: [PATCH v3 06/13] pcie/aer: helper functions for pcie aer capability.
Date: Mon, 27 Sep 2010 12:36:37 +0200 [thread overview]
Message-ID: <20100927103636.GA6374@redhat.com> (raw)
In-Reply-To: <20100927060324.GA28732@valinux.co.jp>
On Mon, Sep 27, 2010 at 03:03:24PM +0900, Isaku Yamahata wrote:
> On Sun, Sep 26, 2010 at 02:46:51PM +0200, Michael S. Tsirkin wrote:
> > > > > +static inline void pcie_aer_errmsg(PCIDevice *dev, const PCIE_AERErrMsg *msg)
> > > > > +{
> > > > > + assert(pci_is_express(dev));
> > > > > + assert(dev->exp.aer_errmsg);
> > > > > + dev->exp.aer_errmsg(dev, msg);
> > > >
> > > > Why do we want the indirection? Why not have users just call the function?
> > >
> > > To handle error signaling uniformly.
> > > Please see
> > > 6.2.5. Sequence of Device Error Signaling and Logging Operations
> > > and figure 6-2 and 6-3.
> >
> > My question was: the only difference appears to be between bridge and
> > non-bridge devices: bridge has to do more stuff, but most code is
> > common. So this seems to be a very roundabout way to do this.
> > Can't we just have a common function with an if (bridge) statement up front?
> > If we ever only expect 2 implementations, I think a function pointer
> > is overkill.
>
> Not 2, but 3. root port, upstream or downstream and normal device.
> So you want something like the following?
> More than 2 is a good reason for me, I prefer function pointer.
Heh, shall we change all switch statements to pointers then?
That's not a good idea IMO, automated tools like ctags
become useless for navigation, you have to look up where it's
actually set. We do have these things in places where
it brings benefit, which is typically where it can take
different values at runtime.
> switch (pcie_cap_get_type(dev))
> case PCI_EXP_TYPE_ROOT_PORT:
> pcie_aer_errmsg_root_port();
> break;
> case PCI_EXP_TYPE_DOWNSTREAM:
> case PCI_EXP_TYPE_UPSTREAM:
> pcie_aer_errmsg_vbridge();
> break;
> default:
> pcie_aer_errmsg_alldev();
> break;
Yes, and note that in fact it's not even that:
all of root and ports are also devices, so we end up
with:
if (pcie_is_root_port(dev)) {
pcie_aer_errmsg_root_port();
} else if (pcie_is_bridge_port(dev)) {
pcie_aer_errmsg_vbridge();
}
pcie_aer_errmsg_alldev();
which is in fact cleaner than calling pcie_aer_errmsg_alldev
from pcie_aer_errmsg_vbridge, I think.
>
> --
> yamahata
next prev parent reply other threads:[~2010-09-27 10:42 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 5:38 [Qemu-devel] [PATCH v3 00/13] pcie port switch emulators Isaku Yamahata
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 01/13] msi: implemented msi Isaku Yamahata
2010-09-15 13:03 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 02/13] pci: implement RW1C register framework Isaku Yamahata
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 03/13] pci: introduce helper function pci_shift_word/long which returns shifted value Isaku Yamahata
2010-09-15 12:49 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-19 4:13 ` Isaku Yamahata
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 04/13] pcie: add pcie constants to pcie_regs.h Isaku Yamahata
2010-09-20 18:14 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 05/13] pcie: helper functions for pcie capability and extended capability Isaku Yamahata
2010-09-15 12:43 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-19 4:56 ` Isaku Yamahata
2010-09-19 11:45 ` Michael S. Tsirkin
2010-09-24 2:24 ` Isaku Yamahata
2010-09-26 12:32 ` Michael S. Tsirkin
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 06/13] pcie/aer: helper functions for pcie aer capability Isaku Yamahata
2010-09-22 11:50 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-24 2:50 ` Isaku Yamahata
2010-09-26 12:46 ` Michael S. Tsirkin
2010-09-27 6:03 ` Isaku Yamahata
2010-09-27 10:36 ` Michael S. Tsirkin [this message]
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 07/13] pcie port: define struct PCIEPort/PCIESlot and helper functions Isaku Yamahata
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 08/13] pcie root port: implement pcie root port Isaku Yamahata
2010-09-22 11:25 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-24 5:38 ` Isaku Yamahata
2010-09-26 12:49 ` Michael S. Tsirkin
2010-09-27 6:36 ` Isaku Yamahata
2010-09-26 12:50 ` Michael S. Tsirkin
2010-09-27 6:22 ` Isaku Yamahata
2010-09-27 10:40 ` Michael S. Tsirkin
2010-09-27 23:01 ` Isaku Yamahata
2010-09-28 9:27 ` Michael S. Tsirkin
2010-09-28 10:38 ` Michael S. Tsirkin
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 09/13] pcie upstream port: pci express switch upstream port Isaku Yamahata
2010-09-22 11:22 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 10/13] pcie downstream port: pci express switch downstream port Isaku Yamahata
2010-09-22 11:22 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 11/13] pcie/hotplug: glue pushing attention button command. pcie_abp Isaku Yamahata
2010-09-22 11:30 ` [Qemu-devel] " Michael S. Tsirkin
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 12/13] pcie/aer: glue aer error injection into qemu monitor Isaku Yamahata
2010-09-15 5:38 ` [Qemu-devel] [PATCH v3 13/13] msix: clear not only INTA, but all INTx when MSI-X is enabled Isaku Yamahata
2010-09-20 18:18 ` [Qemu-devel] Re: [PATCH v3 00/13] pcie port switch emulators Michael S. Tsirkin
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=20100927103636.GA6374@redhat.com \
--to=mst@redhat.com \
--cc=etmartin@cisco.com \
--cc=qemu-devel@nongnu.org \
--cc=skandasa@cisco.com \
--cc=wexu2@cisco.com \
--cc=yamahata@valinux.co.jp \
/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).