From: Thomas Monjalon <thomas@monjalon.net>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, Ilya Maximets <i.maximets@samsung.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Jan Blunck <jblunck@infradead.org>,
Qi Zhang <qi.z.zhang@intel.com>,
Kevin Traynor <ktraynor@redhat.com>,
dpdk stable <stable@dpdk.org>,
Gaetan Rivet <gaetan.rivet@6wind.com>
Subject: Re: [dpdk-dev] [PATCH v2] eal: fix positive error codes from probe/remove
Date: Wed, 26 Jun 2019 23:03:34 +0200 [thread overview]
Message-ID: <3764324.XPBHOOOE6Y@xps> (raw)
In-Reply-To: <CAJFAV8ygt3nQE6Jg0YAeHE+paqLfJ2=8ULg1ksMXM83wv5BD=g@mail.gmail.com>
07/06/2019 10:32, David Marchand:
> Thomas,
>
> - Calling unplug on a device that is not attached is a bit weird to me, all
> the more so that we have rte_dev_probed().
> But there might be users calling directly the bus unplug api and not the
> official api...
> Does this enter the ABI stability perimeter?
> If not, I would be for changing unplug api so that we only deal with 0 or <
> 0 on remove path.
Where the positive value is documented?
If it's only a non-documented usage, I tend to think it can be changed.
> On the plug side, is there a reason why we do not check for
> rte_dev_probed() and let the bus replies that the device is already probed?
A device can be re-probed to allow discovering new ports.
> Does it have something to do with representors ?
> Only guessing.
Yes representors are a case of ports which can appear on a new probe.
> - On the plug side again, can't we have an indication from the buses that
> they have a driver that can handle the device rather than this odd (and
> historical) > 0 return code?
> This should not change the current behavior, just make the code a bit
> easier to understand.
The positive code is also used for white/blacklist.
And I think we may need to try probing in order to give a final answer,
in general case.
next prev parent reply other threads:[~2019-06-26 21:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190530132538eucas1p28fcfddad5b73d3a0baf7095f25a6c1fd@eucas1p2.samsung.com>
2019-05-30 13:25 ` [dpdk-dev] [PATCH] " Ilya Maximets
2019-06-03 8:50 ` [dpdk-dev] [dpdk-stable] " David Marchand
2019-06-03 15:37 ` Ilya Maximets
2019-06-03 16:13 ` David Marchand
2019-06-06 8:39 ` Ilya Maximets
[not found] ` <CGME20190606100234eucas1p2a73029a37495cde21bce3b9a3b023ac4@eucas1p2.samsung.com>
2019-06-06 10:02 ` [dpdk-dev] [PATCH v2] " Ilya Maximets
2019-06-07 8:32 ` David Marchand
2019-06-26 21:03 ` Thomas Monjalon
2019-06-27 7:37 ` David Marchand
2019-06-26 21:03 ` Thomas Monjalon [this message]
2019-06-29 19:30 ` Thomas Monjalon
2019-06-17 10:54 ` Ilya Maximets
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=3764324.XPBHOOOE6Y@xps \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
--cc=i.maximets@samsung.com \
--cc=jblunck@infradead.org \
--cc=ktraynor@redhat.com \
--cc=qi.z.zhang@intel.com \
--cc=stable@dpdk.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).