[dpdk-dev] [PATCH v2 01/11] bus: add bus iterator to find a particular bus
jblunck at infradead.org
Wed Jun 7 18:55:21 CEST 2017
On Wed, Jun 7, 2017 at 3:27 PM, Gaëtan Rivet <gaetan.rivet at 6wind.com> wrote:
> On Wed, Jun 07, 2017 at 12:36:53PM +0530, Shreyansh Jain wrote:
>> >diff --git a/lib/librte_eal/common/include/rte_bus.h b/lib/librte_eal/common/include/rte_bus.h
>> >index 7c36969..006feca 100644
>> >--- a/lib/librte_eal/common/include/rte_bus.h
>> >+++ b/lib/librte_eal/common/include/rte_bus.h
>> >@@ -141,6 +141,38 @@ int rte_bus_probe(void);
>> > void rte_bus_dump(FILE *f);
>> > /**
>> >+ * Bus match function.
>> >+ *
>> >+ * @param bus
>> >+ * bus under test.
>> >+ *
>> >+ * @param data
>> >+ * data matched
>> >+ *
>> >+ * @return
>> >+ * 0 if the bus does not match.
>> >+ * !0 if the bus matches.
>> One of the common match function implementation could be simply to match
>> a string. strcmp itself returns '0' for a successful match.
>> On the same lines, should this function return value be reversed?
>> 0 if match
>> !0 if not a match
>> That way, people would not have to change either the way strcmp works,
>> for example, or the way various APIs expect '0' as success.
>> same for rte_device_match_t as well. (in next patch)
> It was actually a point I hesitated a little before submitting this
> The logic behind strcmp is that you can express three states: greater
> than, equal, lower than, thus having total order within the string set.
> Here, buses are not ordered (logically). Having a bus lower or greater
> than some arbitrary data does not mean much.
> Anyway, this was my reasoning for following Jan's proposal on this, but
> I'm not against changing this API. Maybe having to possibility to
> express total order could be useful eventually. I don't have a strong
> opinion on this so unless someone shouts about it, I will follow your
It is better to have consistency on the match/comparator behavior.
Also if it comes as a surprise to users lets change it.
More information about the dev