From: David Marchand <david.marchand@redhat.com>
To: Tiwei Bie <tiwei.bie@intel.com>
Cc: dev <dev@dpdk.org>, "Burakov, Anatoly" <anatoly.burakov@intel.com>
Subject: Re: [dpdk-dev] [RFC PATCH] bus/pci: avoid depending on private value in kernel source
Date: Wed, 3 Jul 2019 11:10:21 +0200 [thread overview]
Message-ID: <CAJFAV8xC+ovkiNcfn2iJW=48sqUM9c2ZeRHjuVW49DTZ44tsVg@mail.gmail.com> (raw)
In-Reply-To: <20190703085929.GA30592@___>
On Wed, Jul 3, 2019 at 11:01 AM Tiwei Bie <tiwei.bie@intel.com> wrote:
> On Wed, Jul 03, 2019 at 10:26:39AM +0200, David Marchand wrote:
> > This patch breaks the ABI by extending rte_pci_device.
> > You must rework it to avoid this break.
>
> I didn't expect it to be merged in this release. I just want
> to draw other's attention on this and kick off the discussion
> (it would be great if you would like to share your thoughts
> on this). If there is a way to avoid extending rte_pci_device,
> it would be definitely great. But if we have to break it, then
> we would want to send out the announce as early as possible.
>
What we have here is a vfio private thing, we don't need it to be exposed.
Did not think it through yet.
How about having an internal (as in, in the pci driver code) representation
of the pci devices?
This internal structure would embed the rte_pci_device exposed to the
others subsystems and the applications and the vfio code would just get
what it wants by using offsetof?
--
David Marchand
next prev parent reply other threads:[~2019-07-03 9:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 5:45 Tiwei Bie
2019-07-03 7:02 ` David Marchand
2019-07-03 7:33 ` Tiwei Bie
2019-07-03 7:36 ` David Marchand
2019-07-03 7:56 ` Tiwei Bie
2019-07-03 8:01 ` David Marchand
2019-07-03 8:15 ` Tiwei Bie
2019-07-03 8:26 ` David Marchand
2019-07-03 8:59 ` Tiwei Bie
2019-07-03 9:10 ` David Marchand [this message]
2019-07-03 9:25 ` Tiwei Bie
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='CAJFAV8xC+ovkiNcfn2iJW=48sqUM9c2ZeRHjuVW49DTZ44tsVg@mail.gmail.com' \
--to=david.marchand@redhat.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=tiwei.bie@intel.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).