From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id BB5561B4FD for ; Wed, 11 Jul 2018 10:41:33 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id v3-v6so1646938wmh.0 for ; Wed, 11 Jul 2018 01:41:33 -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=0AxYTMxvrMwsP3bC5um4lzXGrMDmYXswINB/COPDzOs=; b=tf2oyR/kIOAQnEqyu3xZm3FzUYD+LBbhMzuk/Fs7zLwrj3Uk6YEucpqkHqbHWjxcDt FDrn9ErH6ELjcSIB3LjTniAK0Fzy+hXimPXXYH+X6tuxavFYyKUAfEqralwwvKYvsZxk U7+UShsls4GyHSFsBzHjpjahjVLOrdBPPwa78xo060CcLb6V59t56loPN7mUwCSi21Tf KunazLmSvxWugeu8mdxPMaH54a4Tk++E00QAyD+aja+i+Ba9RUR5k8ZWRmn0sZrvgHlG sPif/nG0RbmotEAcOWDQRsHzbRed0tuM79NB/bMaAU3fydbLgwFwxq/yKjXI8DTfVyje B3ow== 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=0AxYTMxvrMwsP3bC5um4lzXGrMDmYXswINB/COPDzOs=; b=AoaBQVVXvt50QuElcCjZWBx47/9vTXDQkHZ8WdQG7FaSSkrX339QhZAi7vU6gHJzeP mFxEnin1U7YUm1KK9JIXrsiEBcQei8P/vYTM8zGtMahNNr7rviwGbBsCCzm6guOqvJiH oWbqzRPPiA6IhzSK5cyeF4fXb6l83U2lnSWT/5tGGEFKnBZ+e4FWQcrPGw6P+9Cmojbe 9uHb18liXt69RVArZAvxh3TmaEwQvTLvaKVwmFJnVgC31zTkQ8JQdAd4wYWYnBFNLQJh BTo3HsD1Be6YnK2ttDzIGgtuc/v0TR6yhF1wLSIjtlN+VgpMfh8/Kkp6yD7sicOFYt6P D6Dg== X-Gm-Message-State: APt69E3grhliE/5AFGdk7TQ3UuCeF0KIF3cT4/ho/pG6YYZuAYQqYPIx YAFHsk3OhHekp8LN7vSYwI4kE/Dt X-Google-Smtp-Source: AAOMgpea69Clq9jIQlr28/U8LN+3DTYtRVtsA3sCk3Y3UtZl1LZKgA3o3F3bhPz5WUQ94atuNV9Qog== X-Received: by 2002:a1c:6f44:: with SMTP id k65-v6mr15914745wmc.19.1531298493435; Wed, 11 Jul 2018 01:41:33 -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 b1-v6sm1543053wma.23.2018.07.11.01.41.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Jul 2018 01:41:32 -0700 (PDT) Date: Wed, 11 Jul 2018 10:41:16 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Thomas Monjalon Cc: dev@dpdk.org Message-ID: <20180711084116.dbbou4vbbp2y5tcn@bidouze.vm.6wind.com> References: <0a2d77e22658987a6e1e650913f020a140c2c1a9.1530791217.git.gaetan.rivet@6wind.com> <2914659.2M3dPKUJVY@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2914659.2M3dPKUJVY@xps> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v10 08/27] devargs: add function to parse device layers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 08:41:33 -0000 Hi Thomas, On Wed, Jul 11, 2018 at 10:19:07AM +0200, Thomas Monjalon wrote: > 05/07/2018 13:48, Gaetan Rivet: > > +/** > > + * @internal > > + * Parse a device string and store its information in an > > + * rte_devargs structure. > > Please, explain what is a layer. > > > + * > > + * Note: if the "data" field of da points to devstr, > > Better to use "devargs" as variable name, instead of "da". > > > + * then no dynamic allocation is performed and the rte_devargs > > + * can be safely discarded. > > + * > > + * Otherwise ``data`` will hold a workable copy of devstr, that will be > > + * used by layers descriptors within rte_devargs. In this case, > > + * any rte_devargs should be cleaned-up before being freed. > > + * > > + * @param da > > + * rte_devargs structure to fill. > > + * > > + * @param devstr > > + * Device string. > > + * > > + * @return > > + * 0 on success. > > + * Negative errno values on error (rte_errno is set). > > + */ > > +int > > +rte_devargs_layers_parse(struct rte_devargs *da, > > + const char *devstr); > > + > > #endif /* _EAL_PRIVATE_H_ */ > > diff --git a/lib/librte_eal/common/include/rte_devargs.h b/lib/librte_eal/common/include/rte_devargs.h > > index 6c3b6326b..148600258 100644 > > --- a/lib/librte_eal/common/include/rte_devargs.h > > +++ b/lib/librte_eal/common/include/rte_devargs.h > > @@ -51,12 +51,19 @@ struct rte_devargs { > > enum rte_devtype type; > > /** Device policy. */ > > enum rte_dev_policy policy; > > - /** Bus handle for the device. */ > > - struct rte_bus *bus; > > /** Name of the device. */ > > char name[RTE_DEV_NAME_MAX_LEN]; > > + RTE_STD_C11 > > + union { > > /** Arguments string as given by user or "" for no argument. */ > > - char *args; > > + char *args; > > + const char *drvstr; > > + }; > > + struct rte_bus *bus; /**< bus handle. */ > > + struct rte_class *cls; /**< class handle. */ > > "class" is more readable than "cls" > I was thinking that maybe this could be a problem when trying to build with C++. The EAL headers in DPDK are meant to be included in C++ apps, I think ``class`` would be an issue then. If I'm mistaken, then sure, class is a better name. > > + const char *busstr; /**< bus-related part of device string. */ > > bus_str ? > > > + const char *clsstr; /**< bus-related part of device string. */ > > class_str ? > + there is a typo in the comment (copy/pasted "bus") > > > + const char *data; /**< Device string storage. */ > > }; > > > Otherwise, ok with the rest of the comments, will fix (as well as the previous emails). Thanks for reading. -- Gaëtan Rivet 6WIND