From: Christoph Hellwig <hch@lst.de>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Keith Busch <keith.busch@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
"Duyck, Alexander H" <alexander.h.duyck@intel.com>,
linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org,
kvm@vger.kernel.org, Netdev <netdev@vger.kernel.org>,
"Daly, Dan" <dan.daly@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-nvme@lists.infradead.org, netanel@amazon.com,
Maximilian Heyne <mheyne@amazon.de>,
"Wang, Liang-min" <liang-min.wang@intel.com>,
"Rustad, Mark D" <mark.d.rustad@intel.com>,
David Woodhouse <dwmw2@infradead.org>,
Christoph Hellwig <hch@lst.de>,
dwmw@amazon.co.uk
Subject: Re: [pci PATCH v5 1/4] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
Date: Tue, 13 Mar 2018 08:44:05 +0100 [thread overview]
Message-ID: <20180313074405.GA32480@lst.de> (raw)
In-Reply-To: <CAKgT0UfH+xXk__R_hEtFMsm7qkBG02hWC-S=8MgYkeeEx5zweA@mail.gmail.com>
On Mon, Mar 12, 2018 at 01:17:00PM -0700, Alexander Duyck wrote:
> No, I am aware of those. The problem is they aren't accessed as
> function pointers. As such converting them to static inline functions
> is easy. As I am sure you are aware an "inline" function doesn't
> normally generate a function pointer.
I think Keith's original idea of defining them to NULL is right. That
takes care of all the current trivial assign to struct cases.
If someone wants to call these functions they'll still need the ifdef
around the call as those won't otherwise compile, but they probably
want the ifdef around the whole caller anyway.
next prev parent reply other threads:[~2018-03-13 7:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 17:20 [pci PATCH v5 0/4] Series short description Alexander Duyck
2018-03-12 17:21 ` [pci PATCH v5 1/4] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources Alexander Duyck
2018-03-12 17:40 ` Keith Busch
2018-03-12 18:09 ` Alexander Duyck
2018-03-12 18:23 ` Keith Busch
2018-03-12 20:17 ` Alexander Duyck
2018-03-13 7:44 ` Christoph Hellwig [this message]
2018-03-12 17:23 ` [pci PATCH v5 2/4] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices Alexander Duyck
2018-03-12 17:23 ` [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support Alexander Duyck
2018-03-13 8:12 ` David Woodhouse
2018-03-13 8:16 ` Christoph Hellwig
2018-03-13 8:45 ` David Woodhouse
2018-03-13 8:54 ` Christoph Hellwig
2018-03-13 9:14 ` David Woodhouse
2018-03-13 14:51 ` Alexander Duyck
2018-03-13 15:04 ` David Woodhouse
2018-03-13 16:17 ` Don Dutile
2018-03-12 17:23 ` [pci PATCH v5 4/4] nvme: " Alexander Duyck
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=20180313074405.GA32480@lst.de \
--to=hch@lst.de \
--cc=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=bhelgaas@google.com \
--cc=dan.daly@intel.com \
--cc=dwmw2@infradead.org \
--cc=dwmw@amazon.co.uk \
--cc=keith.busch@intel.com \
--cc=kvm@vger.kernel.org \
--cc=liang-min.wang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=mark.d.rustad@intel.com \
--cc=mheyne@amazon.de \
--cc=netanel@amazon.com \
--cc=netdev@vger.kernel.org \
--cc=virtio-dev@lists.oasis-open.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).