From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 23479683E for ; Wed, 17 Oct 2018 16:20:25 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9AA942214C; Wed, 17 Oct 2018 10:20:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 17 Oct 2018 10:20:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=rHf+50/87ICN1x5tg310oxqwCaM3r62mBxJnyQyiExI=; b=AEHgXr2dtR/e G2Mjg4eG0d0a5/T/vWRBpwfj2xygbnTqPKtmeZczk8dK/JeUvcSQvrSrM9mWt8a7 AQMgfiEtgxoDMF1V3ypbsifQ8gkMQcPLz6TVH5C9sGb45w+f+fCOJEnsMUKfeGxQ aWa5qBjCTKUzq4VXJsgzLbqGzSEQdz8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=rHf+50/87ICN1x5tg310oxqwCaM3r62mBxJnyQyiE xI=; b=OIwNqdvlnpuRhYhQhU8nzT2wSD8yj4Zml5cxqU5C7trWHllFkdZQvDkEZ iJdKE4J4OGktt/UweZGqdzP+vChaRDEoUor6HVTLGnlY311Uyzi6EBopFZawuD4r 0V9mqXS0DcNNwWsTbIdr1gSzdh579H0oeRNqfbU2ygPeVTnc8lumy7QOzT1WJiUs 1aBxaQeeVt9O1D1Vu+cy04hcW2bKoGJ0IgP4UGw6DW0HcBR4H3M5fieC/wdVnHE3 SaOfmcHQDWu1FK4JvnG1mjTxN7EFcKjPO75thTM8d0Ygqs7VKd6toS+FgbtPirK2 5oxbqZIcuOQl29+2I7l7kvjy/67WQ== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7E423102F1; Wed, 17 Oct 2018 10:20:22 -0400 (EDT) From: Thomas Monjalon To: "Laatz, Kevin" Cc: =?ISO-8859-1?Q?Ga=EBtan?= Rivet , dev@dpdk.org, harry.van.haaren@intel.com, stephen@networkplumber.org, shreyansh.jain@nxp.com, mattias.ronnblom@ericsson.com, bruce.richardson@intel.com Date: Wed, 17 Oct 2018 16:20:25 +0200 Message-ID: <4974925.MPkd7eIPCQ@xps> In-Reply-To: References: <20181011165837.81030-1-kevin.laatz@intel.com> <5281106.4Q2nRubcPx@xps> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH v5 01/13] eal: add param register infrastructure 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, 17 Oct 2018 14:20:25 -0000 17/10/2018 16:09, Laatz, Kevin: > Hi Thomas, >=20 >=20 > On 17/10/2018 14:46, Thomas Monjalon wrote: > > 17/10/2018 13:45, Ga=EBtan Rivet: > >> Hi Thomas, > >> > >> On Wed, Oct 17, 2018 at 11:41:53AM +0200, Thomas Monjalon wrote: > >>> I still think all the wording is incorrect. > >>> Please start by describing what is "param", "flag" and "option" in yo= ur mind. > >>> They are all mentioned in this file. > >>> Are you sure rte_param is the right name? > >>> > >> I suggested the name rte_param, I think the original proposal was > >> rte_lib_init, which to me unduly diminished the intent of these struct= ures. > > I think the right word is "run-time option". > > An option can have a parameter. > > If this API is not supporting options with parameters, the name is > > really misleading. > The option will be passed like any other EAL option. Right now it=20 > doesn't support any parameters but in future we could add functionality=20 > like we had with the --vdev solution where we can pass selftest=3D1 with= =20 > the telemetry option. > > > >> I think rte_param seems proper, this is a generic parameter object > >> description. The integer "enabled" is described as a flag in the > >> structure, as it is used to flag the init routine down the road to > >> trigger the init callback associated with this parameter. > > "enabled" can be documented as the result of the option parsing. > > If the option is given to rte_eal_init, it becomes enabled. > The Doxygen comments mention that the flag should initially be set to 0=20 > and will be set to 1 if the option for the relevant callback is passed=20 > to EAL when running your application. Saying "passed to EAL" is too vague. You need to differentiate the option parsing and the init. Both are done in EAL, that's why you need to be more specific. > >> eal_option is reminiscent of optarg / optind of getopt() family, > >> which seems fitting. > >> > >> I don't mean to overstep Kevin's role defending his work, but given > >> that I proposed some of this naming and pushed for this direction to be > >> taken in the first place, I feel I should help explain my propositions. > >> > >> rte_param could become rte_parameter or rte_option instead, eal_option > >> could become opt_string or opt_str, and so on, do you have specific > >> ideas about proper names? > > rte_option looks OK. > I'm happy to change it to rte_option if we have consensus on it :) OK, thanks > > The global picture may be better explained I think. > > Any help with wording and documentation is appreciated, thanks. >=20 > Thanks, > Kevin >=20 >=20