On Wed, Jun 7, 2017 at 3:27 PM, Gaëtan Rivet <gaetan.ri...@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.
