On Thu, Jun 08, 2017 at 04:34:50AM +0000, Shreyansh Jain wrote: > Hello Gaëtan, > > > -----Original Message----- > > From: Gaëtan Rivet [mailto:gaetan.ri...@6wind.com] > > Sent: Wednesday, June 07, 2017 6:58 PM > > To: Shreyansh Jain <shreyansh.j...@nxp.com> > > Cc: dev@dpdk.org; Jan Blunck <jblu...@infradead.org> > > Subject: Re: [PATCH v2 01/11] bus: add bus iterator to find a particular bus > > > > On Wed, Jun 07, 2017 at 12:36:53PM +0530, Shreyansh Jain wrote: > > > Hello Gaetan, > > > > > > On Wednesday 31 May 2017 06:47 PM, Gaetan Rivet wrote: > > > >From: Jan Blunck <jblu...@infradead.org> > > > > > > > >Signed-off-by: Jan Blunck <jblu...@infradead.org> > > > >Signed-off-by: Gaetan Rivet <gaetan.ri...@6wind.com> > > > >--- > > > > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 + > > > > lib/librte_eal/common/eal_common_bus.c | 13 ++++++++++ > > > > lib/librte_eal/common/include/rte_bus.h | 32 > > +++++++++++++++++++++++++ > > > > lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 + > > > > 4 files changed, 47 insertions(+) > > > > > > > >diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map > > b/lib/librte_eal/bsdapp/eal/rte_eal_version.map > > > >index 2e48a73..ed09ab2 100644 > > > >--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map > > > >+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map > > > >@@ -162,6 +162,7 @@ DPDK_17.02 { > > > > DPDK_17.05 { > > > > global: > > > >+ rte_bus_find; > > > > rte_cpu_is_supported; > > > > rte_log_dump; > > > > rte_log_register; > > > >diff --git a/lib/librte_eal/common/eal_common_bus.c > > b/lib/librte_eal/common/eal_common_bus.c > > > >index 8f9baf8..68f70d0 100644 > > > >--- a/lib/librte_eal/common/eal_common_bus.c > > > >+++ b/lib/librte_eal/common/eal_common_bus.c > > > >@@ -145,3 +145,16 @@ rte_bus_dump(FILE *f) > > > > } > > > > } > > > > } > > > >+ > > > >+struct rte_bus * > > > >+rte_bus_find(rte_bus_match_t match, const void *data) > > > >+{ > > > >+ struct rte_bus *bus = NULL; > > > >+ > > > >+ TAILQ_FOREACH(bus, &rte_bus_list, next) { > > > >+ if (match(bus, data)) > > > >+ break; > > > >+ } > > > >+ > > > >+ return bus; > > > >+} > > > >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. > > I agree about the match() fn - but, this is not what I meant. > My point was that ideally for implementation of callbacks, applications > would more often use the strcmp function (matching name of the bus) than > the match() callback. > > Further, this semantic is being followed by other DPDK APIs as well - so, > my intent was to make this also inline with those. >
Ah, I see your point now. It makes sense. The API is now the same. > > > > 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. > > Thank you! > > > > <...snip...> -- Gaëtan Rivet 6WIND
