From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v5 01/13] eal: add param register infrastructure Date: Wed, 17 Oct 2018 15:46:42 +0200 Message-ID: <5281106.4Q2nRubcPx@xps> References: <20181011165837.81030-1-kevin.laatz@intel.com> <25255353.InYxgXp6IK@xps> <20181017114550.kugn4tzo6h2svur3@bidouze.vm.6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Kevin Laatz , dev@dpdk.org, harry.van.haaren@intel.com, stephen@networkplumber.org, shreyansh.jain@nxp.com, mattias.ronnblom@ericsson.com, bruce.richardson@intel.com To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Return-path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 33A654F91 for ; Wed, 17 Oct 2018 15:46:44 +0200 (CEST) In-Reply-To: <20181017114550.kugn4tzo6h2svur3@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" 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