From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by dpdk.org (Postfix) with ESMTP id 3AA905F12 for ; Wed, 17 Oct 2018 13:46:10 +0200 (CEST) Received: by mail-wm1-f66.google.com with SMTP id 189-v6so1692506wmw.2 for ; Wed, 17 Oct 2018 04:46:10 -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=Ku5aUowTpucZALx2AQUJ6s45Bo0qHeereIDDUsy7dRA=; b=mlFgr0kQ7I6LAqgzi1ppWgq1+sMKEMOVUkhGZ++ne/vvREBT/pkqLv8ZxoIcM6KrbO TCfRJLHnUOAvgYJAFaVnD7LLsexT8xLZb6Vu2TyUwK2Wd0Ai2LEwjvmsyck3jlt4I6yw EZTwOFbOyEZlsiXpk7kGOkSEXDMBUhguZBGue6h07jKQaseixIDv4ctwjDkECvbQd6ue 6PxGh0vytj1VCdNikdO9AopkplharHH62Vnu43QC5+KYbhMhkO90bMvqDZm2N39MmW6M +3bG2Xn6zyU+WdUHaXBlMEB5TcRIYAG1hkjAIp7c+AFiydIK8jskxbgQ4IFpXM0HYA6k HR7g== 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=Ku5aUowTpucZALx2AQUJ6s45Bo0qHeereIDDUsy7dRA=; b=Kqec9pmOhkYJQvWjZcwPFI8W0zj9vZB5mD4go+8WFz73UOT76frE6SdE+WsxVQiyf9 hkbceYOTfCbbx+tdtyX3+VBcA60jvWBeBTGHm8Ape1Sdh+oZY//YJHfomlZLxyUqmIE7 NsIpbL9GTYzM241A9D2tMEg3Dwhj4MpZGXRgiMDbYsHHfoNWv5vWxrG4dDVYKeoGfA/z 71YSpNcz7hQN1h+KPDnSSN9/upZ+O0znUarA08M9B9lR3eBV0RmVZsqvk1yvEPoeSVyk 6kJHJ7lY+hmP7mnbnUvuyGZpac0VIvy0Md5JfPyxSYfB3uU1COAc6oypSyUWuoILo0gV mjog== X-Gm-Message-State: ABuFfojOF+9XZff7pbOb2VJ/G+c2Qbdj7m2EA4Kxr5zvbwOt53iYtkG8 PfROCW6TaZrqjjgFgDEhGR0MhQ== X-Google-Smtp-Source: ACcGV63snAJrsRTYqcndlXIikwNt7bRs2o6uuCNum5ahbr/mUpT0mV7J5QL8F/by11D3IwoMwaidIg== X-Received: by 2002:a1c:e5cf:: with SMTP id c198-v6mr2510207wmh.113.1539776769510; Wed, 17 Oct 2018 04:46:09 -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 m2-v6sm10567710wrj.80.2018.10.17.04.46.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Oct 2018 04:46:08 -0700 (PDT) Date: Wed, 17 Oct 2018 13:45:50 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Thomas Monjalon 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 Message-ID: <20181017114550.kugn4tzo6h2svur3@bidouze.vm.6wind.com> References: <20181011165837.81030-1-kevin.laatz@intel.com> <20181016155802.2067-1-kevin.laatz@intel.com> <20181016155802.2067-2-kevin.laatz@intel.com> <25255353.InYxgXp6IK@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <25255353.InYxgXp6IK@xps> User-Agent: NeoMutt/20170113 (1.7.2) 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 11:46:10 -0000 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 your 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 structures. 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. 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? > > 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. When > > + * registering a callback, the application also provides an option as part > > + * of the struct used to register. If the option is passed to EAL when > > + * 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. > > + * Citing --telemetry here is a bad idea, this file is lib-agnostic, --telemetry is not assured to be relevant. > > + * The register API can be used to resolve circular dependency issues > > + * between EAL and the library. The library uses EAL but is also initialized 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 with EAL > > + * (passing a function pointer) and avoid the circular dependency. > > + */ -- Gaëtan Rivet 6WIND