From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Blunck Subject: Re: [PATCH v2 01/11] bus: add bus iterator to find a particular bus Date: Wed, 7 Jun 2017 18:55:21 +0200 Message-ID: References: <33c95f6a-82b4-6557-7011-f210f34cbc88@nxp.com> <20170607132742.GP18840@bidouze.vm.6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: Shreyansh Jain , dev To: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= Return-path: Received: from mail-wr0-f195.google.com (mail-wr0-f195.google.com [209.85.128.195]) by dpdk.org (Postfix) with ESMTP id 8A3FD10A7 for ; Wed, 7 Jun 2017 18:55:22 +0200 (CEST) Received: by mail-wr0-f195.google.com with SMTP id g76so1700607wrd.2 for ; Wed, 07 Jun 2017 09:55:22 -0700 (PDT) In-Reply-To: <20170607132742.GP18840@bidouze.vm.6wind.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Jun 7, 2017 at 3:27 PM, Ga=C3=ABtan Rivet = 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/c= ommon/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.