From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 33A654F91 for <dev@dpdk.org>; Wed, 17 Oct 2018 15:46:44 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B7BE4200E3; Wed, 17 Oct 2018 09:46:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 17 Oct 2018 09:46:42 -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=XI7MaiHglYjqw9TqKLNW33n/4bapbfeEp8aFCzNvQJs=; b=gF3s3vokzlwY kaFgCk3WQWyQ93qTmmc6P67xg5E1UEzAUwpjCk5kJVigBd/FrgUHP5A+t6oJxjQN mCCEXkmjzDXgOB7lpvbLdc1CbN9SnCRwtutAFcYXwvkwPF4oj70JGy5TpTy9ObLO 1E3JF1pDHaAQnLDjCH6p0cwFo2RGKxE= 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=XI7MaiHglYjqw9TqKLNW33n/4bapbfeEp8aFCzNvQ Js=; b=jAI71iIShSZezd16uAvTCad19UB0UgymzUehczlXYiuP6mt6DZj8pNcmg yXgDAAH655H9/k22ZHIPwJAUihaDaWonAEmT9mwJsTmrkVQja3KQujRxjtvwTJCx Zj0hbSzwuPMJwWyePTO129cEBYeFkxOI0CkkyLYUHYc/oOtFhdvKQzJR6ymNrHv3 KM3TlLAggvCgVnZ7U9T4JyL6oLMR4+vnGMWNaT5r/hOhENJDop+MvIr2hfFx/eJR TwU8gTfkc3d1TOVTf7sJjngvAEeUBpFKMoqHFNl/4ymWPjM1u6fXLmNAExqqtsSJ 507Y8KwdwgVeZp9MqhLMZpv+Il+SA== X-ME-Sender: <xms:QT3HW2_V3iDzTg7jmb62W-0JGB2SaAZLWeSUs39Uwzeimj7dtTdubQ> X-ME-Proxy: <xmx:QT3HW0mlkmYRJhY_bXymWL2aPdP-8KroyB1SbrZrySHz-g7GrJ7twA> <xmx:QT3HW4jdyojc0b_--wWS3RLsY2kD4u0M_jSU8QTuG0avCzKPk2LSJg> <xmx:QT3HW6hlOeaPy16-3FYBq_CkGVCIl-PO5MQMtkK2i3D00hybmtC1WQ> <xmx:QT3HW0VlWDH2BnapXzX6FeRhmCEkD86sA_LI5B36q44qMpe2hWb3EA> <xmx:QT3HWw1nuA3tvEXnXtizlliffdw2b3UEQ7-BNC5ALhZSdlbuIprGMw> <xmx:Qj3HW7SuPBW4ZVGJPUSRH966n5kwlnCDJYK_6dMHuvm37BoX-SZmcQ> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id E39E6102F8; Wed, 17 Oct 2018 09:46:40 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com> Cc: Kevin Laatz <kevin.laatz@intel.com>, 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 15:46:42 +0200 Message-ID: <5281106.4Q2nRubcPx@xps> In-Reply-To: <20181017114550.kugn4tzo6h2svur3@bidouze.vm.6wind.com> References: <20181011165837.81030-1-kevin.laatz@intel.com> <25255353.InYxgXp6IK@xps> <20181017114550.kugn4tzo6h2svur3@bidouze.vm.6wind.com> 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 17 Oct 2018 13:46:44 -0000 17/10/2018 13:45, Ga=EBtan Rivet: > Hi Thomas, >=20 > 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 your= mind. > > They are all mentioned in this file. > > Are you sure rte_param is the right name? > >=20 >=20 > I suggested the name rte_param, I think the original proposal was > rte_lib_init, which to me unduly diminished the intent of these structure= s. 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. > 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. > eal_option is reminiscent of optarg / optind of getopt() family, > which seems fitting. >=20 > 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. >=20 > 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. The global picture may be better explained I think. Any help with wording and documentation is appreciated, thanks. > > 16/10/2018 17:57, Kevin Laatz: > > > --- /dev/null > > > +++ b/lib/librte_eal/common/include/rte_param.h > > > @@ -0,0 +1,91 @@ > > > +/* SPDX-License-Identifier: BSD-3-Clause > > > + * Copyright(c) 2018 Intel Corporation. > > > + */ > > > + > > > +#ifndef __INCLUDE_RTE_PARAM_H__ > > > +#define __INCLUDE_RTE_PARAM_H__ > > > + > > > +/** > > > + * @file > > > + * > > > + * This API introduces the ability to register callbacks with EAL. W= hen > > > + * registering a callback, the application also provides an option a= s part > > > + * of the struct used to register. If the option is passed to EAL wh= en > > > + * running a DPDK application, the relevant callback will be called = at the > > > + * end of EAL init. For example, passing --telemetry will make the > > > + * telemetry init be called at the end of EAL init. > > > + * >=20 > Citing --telemetry here is a bad idea, this file is lib-agnostic, > --telemetry is not assured to be relevant. >=20 > > > + * The register API can be used to resolve circular dependency issues > > > + * between EAL and the library. The library uses EAL but is also ini= tialized by > > > + * EAL. Hence, EAL depends on the init function of the library. The = API > > > + * introduced in rte_param allows us to register the library init wi= th EAL > > > + * (passing a function pointer) and avoid the circular dependency. > > > + */ >=20 >=20