[dpdk-dev] [PATCH v2 01/11] bus: add bus iterator to find a particular bus

[Jan Blunck]

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
> version.
>
> 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
> remark.
>

It is better to have consistency on the match/comparator behavior.
Also if it comes as a surprise to users lets change it.