From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gaetan.rivet@6wind.com> Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) by dpdk.org (Postfix) with ESMTP id C7A4C2C8 for <dev@dpdk.org>; Thu, 6 Jul 2017 15:30:57 +0200 (CEST) Received: by mail-wr0-f182.google.com with SMTP id c11so3106775wrc.3 for <dev@dpdk.org>; Thu, 06 Jul 2017 06:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=mlpPn5zHWD+c6EaR2NOTypI5ML/oWlpFg3O28338YLM=; b=FYOUT5JzSqUlRRNynkIlAbsH2CXkBwH/v0Prp0u58wwWotNHGYGVUr4YSG42J9JtLa cOHr++uf/TRzOPWhpGbd1pBJOkXLTcJwFHvWJLHWO7bodbvdGnfclwl0p+z7zL2hPGig W2KjRU3TRi4D4o+SLqAtvDK6FLU7RBIXbcnPgcm2sg6Tl1F0KHPOSn8WQlzZklcA47MN BYu9AMkMGSaRmAtrCEvtrNjV5g4qKDGaJBhmPvhrZf/ZbG4lgFFlUq1kVRmJGvh8lwqp 4NHAmNGY035In6PDkvsU/3/153Toh6mVPvkb7tBs9Hb2PlElQyfJMlV5f2tvXm98nKyz 5Liw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=mlpPn5zHWD+c6EaR2NOTypI5ML/oWlpFg3O28338YLM=; b=A8TVsyMz62O1xQiEk0DftzZ4gqYD2f9B+2qsGghmsp02Bk0Oy9uNR5oAnPMhAbKVp7 b2MPfuMv/6cu6+v58ZJlY2oPNgP0xmSUKQXk9LLhA6L7/IZx5RadE2CC8IDTkVPGn9LJ 0HHdkF7umyzUuz/bfYsRldINJTFQzj3q6b1DzP+5GmuqB7T6Z16ZZxMlTXCkVJnQ8euC hbZYdoTP5pfKuebTjyO+xpHv17jJBuvq7yElSQbFxlrrkNU/Mu3jtBLVffvE4/XQ8zgE aHJP8ltG4NcFX4HZHvKvCyeKfnrSTr4iIWniq1eXSl4pQB1ic7/PAHiuAq8nOZGfMTqp +o3A== X-Gm-Message-State: AKS2vOzS3Xaxrr9qLE3ZcQsue1jSXBpYVIJ2w8sQtvf3hBrOApE2CZGF 5CkqbePQqd4gB2Hywg8= X-Received: by 10.28.71.76 with SMTP id u73mr34999247wma.105.1499347857223; Thu, 06 Jul 2017 06:30:57 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id f21sm230433wra.5.2017.07.06.06.30.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 06:30:56 -0700 (PDT) Date: Thu, 6 Jul 2017 15:30:48 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com> To: santosh <santosh.shukla@caviumnetworks.com> Cc: dev@dpdk.org Message-ID: <20170706133048.GM11154@bidouze.vm.6wind.com> References: <cover.1499211317.git.gaetan.rivet@6wind.com> <e3109f1a96e03902a6057a49f0f96cb4e3325687.1499211317.git.gaetan.rivet@6wind.com> <a3503ae0-10fd-9fba-29a5-ea753887acee@caviumnetworks.com> <20170706123012.GL11154@bidouze.vm.6wind.com> <9e8b63fb-2687-8cff-5f9f-e34dc16ff364@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9e8b63fb-2687-8cff-5f9f-e34dc16ff364@caviumnetworks.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v7 2/6] bus: introduce parsing functionality X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 06 Jul 2017 13:30:58 -0000 On Thu, Jul 06, 2017 at 06:42:23PM +0530, santosh wrote: > On Thursday 06 July 2017 06:00 PM, Gaëtan Rivet wrote: > > > On Thu, Jul 06, 2017 at 02:49:41PM +0530, santosh wrote: > >> Hi Gaetan, > >> > >> On Wednesday 05 July 2017 05:25 AM, Gaetan Rivet wrote: > >> > >>> This operation can be used either to validate that a device > >>> representation can be understood by a bus, as well as store the resulting > >>> specialized device representation in any format determined by the bus. > >>> > >>> Signed-off-by: Gaetan Rivet <gaetan.rivet@6wind.com> > >>> --- > >>> lib/librte_eal/common/include/rte_bus.h | 21 +++++++++++++++++++++ > >>> 1 file changed, 21 insertions(+) > >>> > >>> diff --git a/lib/librte_eal/common/include/rte_bus.h b/lib/librte_eal/common/include/rte_bus.h > >>> index 773b0d7..aebf57e 100644 > >>> --- a/lib/librte_eal/common/include/rte_bus.h > >>> +++ b/lib/librte_eal/common/include/rte_bus.h > >>> @@ -138,6 +138,26 @@ typedef int (*rte_bus_plug_t)(struct rte_device *dev, > >>> typedef int (*rte_bus_unplug_t)(struct rte_device *dev); > >>> > >>> /** > >>> + * Bus specific parsing function. > >>> + * Validates the syntax used in the textual representation of a device, > >>> + * If the syntax is valid and ``addr`` is not NULL, writes the bus-specific > >>> + * device representation to ``addr``. > >>> + * > >>> + * @param[in] name > >>> + * device textual description > >>> + * > >>> + * @param[out] addr > >>> + * device information location address, into which parsed info > >>> + * should be written. If NULL, nothing should be written, which > >>> + * is not an error. > >>> + * > >> r / is not a error/ is valid? > >> > > I'm partial to "is not an error" here, but it doesn't matter that much > > and I can change it if you prefer. > > > >>> + * @return > >>> + * 0 if parsing was successful. > >>> + * !0 for any error. > >>> + */ > >>> +typedef int (*rte_bus_parse_t)(const char *name, void *addr); > >>> + > >> _parse handler in _common_vdev or common_pci file return boolean value > >> i.e..0 for success and 1 for error, right? if so then > >> !0 for any error would be like '1' for error case.. make sense? > >> > > I thought of that yes, and actually your suggestion was the first > > version I used. > > > > Ultimately however, this function is not only saying "can parse": it is > > not merely a test of being able to process the input, but also the > > process itself. The test value is then a byproduct. > > > > As such, I decided to settle on the standard "0 means nothing of note > > happened, carry on". > > I'm not aware of past work history, catching up with stuff so no > strong opinion but In my opinion: if we're sure about return values then better > mention them explicitly. > That's the way it has been implemented in vdev and pci, but other buses might want to use internal helpers in their version, that might return something else than 1 on error. As such, I think it's better to push the weakest specification sufficient to match our needs and not force unnecessary hoops on developers downstream. > Thanks. > > -- Gaëtan Rivet 6WIND