From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C5B9DA054F; Mon, 15 Mar 2021 18:02:03 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3D4CE242747; Mon, 15 Mar 2021 18:02:03 +0100 (CET) Received: from dal3relay211.mxroute.com (dal3relay211.mxroute.com [64.40.27.211]) by mails.dpdk.org (Postfix) with ESMTP id 8BF0B242741 for ; Mon, 15 Mar 2021 18:02:01 +0100 (CET) Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by dal3relay211.mxroute.com (ZoneMTA) with ESMTPSA id 17836d6501b00092ce.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Mon, 15 Mar 2021 17:01:58 +0000 X-Zone-Loop: 1e3632e41713d05a9f307e0ea1fc89ca82ab8211fbd9 X-Originating-IP: [149.28.56.236] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=s/zth3mDX/pQolZejBxFpX+bAElYZSF5X0mWVSygrZ0=; b=dnl5HVLbiw3DnPAS3vDLLBLdjN P6h4ymfKY1E2ad2nMp6UbCzbXEO9fXyaSMv+fgF8bEY+4MiK7gh4ojP0yQa5nZo6l13d82RkRutzi UjiL0O5gjqyt4St+lNcALZHCFIM1JTiYgOjmBFxbiDnK4/+cBjWZf5st6u8Ye6gTXJev54AjIhxGN 846AT9jkOzkzKHb1m2JnxZeomo60MOO/As6j/zP1EJe7Qv3zfxOrpgzsWa5cgQZ5VgI9VCmZh32Yl HqQTuMxxL0GuYTIycFSlIzsv+HCH41D4/HR8l+Uq52kk5pAbGoJxVj+E93P3lQ7eDbyS27gzohfna dNfc/aWQ==; To: Stephen Hemminger , Thomas Monjalon Cc: Bruce Richardson , dev@dpdk.org, david.marchand@redhat.com, mb@smartsharesystems.com, Neil Horman References: <20210309233116.1934666-1-thomas@monjalon.net> <20210315103144.GC2040@bricha3-MOBL.ger.corp.intel.com> <4942393.sW9uhsZSEm@thomas> <20210315085941.2367c953@hermes.local> From: "Kinsella, Ray" Message-ID: Date: Mon, 15 Mar 2021 17:01:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <20210315085941.2367c953@hermes.local> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] [PATCH v3 07/11] eal: add log level help X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 15/03/2021 15:59, Stephen Hemminger wrote: > On Mon, 15 Mar 2021 11:52:13 +0100 > Thomas Monjalon wrote: > >> 15/03/2021 11:42, Kinsella, Ray: >>> >>> On 15/03/2021 10:31, Bruce Richardson wrote: >>>> On Mon, Mar 15, 2021 at 10:19:47AM +0000, Kinsella, Ray wrote: >>>>> >>>>> >>>>> On 12/03/2021 18:17, Thomas Monjalon wrote: >>>>>> The option --log-level was not completely described in the usage text, >>>>>> and it was difficult to guess the names of the log types and levels. >>>>>> >>>>>> A new value "help" is accepted after --log-level to give more details >>>>>> about the syntax and listing the log types and levels. >>>>>> >>>>>> The array "levels" used for level name parsing is replaced with >>>>>> a (modified) existing function which was used in rte_log_dump(). >>>>>> >>>>>> The new function rte_log_list_types() is exported in the API >>>>>> for allowing an application to give this info to the user >>>>>> if not exposing the EAL option --log-level. >>>>>> The list of log types cannot include all drivers if not linked in the >>>>>> application (shared object plugin case). >>>>>> >>>>>> Signed-off-by: Thomas Monjalon >>>>>> --- >>>>>> lib/librte_eal/common/eal_common_log.c | 24 +++++++++--- >>>>>> lib/librte_eal/common/eal_common_options.c | 44 +++++++++++++++------- >>>>>> lib/librte_eal/common/eal_log.h | 5 +++ >>>>>> lib/librte_eal/include/rte_log.h | 11 ++++++ >>>>>> lib/librte_eal/version.map | 3 ++ >>>>>> 5 files changed, 69 insertions(+), 18 deletions(-) >>>>>> >>>> >>>>>> @@ -1274,6 +1286,11 @@ eal_parse_log_level(const char *arg) >>>>>> char *str, *level; >>>>>> int priority; >>>>>> >>>>>> + if (strcmp(arg, "help") == 0) { >>>>> >>>>> So I think the convention is to support both "?" and "help". >>>>> Qemu does this at least. >>>>> >>>> I've seen "/?" used for help on windows binaries, but "-?" not so much in the >>>> linux world, where --help (and often -h for short) seem to be the standard. >>>> >>> >>> This is slightly different - it is where you are looking to return a list of valid >>> values for a parameter. So for instance in qemu mentioned above >>> >>> ~ > qemu-system-x86_64 -cpu ? | head -n 10 >> >> "?" is a special character. >> In my zsh, I need to quote it to avoid globbing parsing, >> so I'm not a fan. >> >> I will let you extend the syntax in a separate patch :) >> >> > > Also '?' is used by getopt to match unknown option. So qemu might just be > doing that as unintended side effect of any unknown option > for other unknowns it explicitly complains ... ~ > qemu-system-x86_64 -cpu unknown Unable to init server: Could not connect: Connection refused qemu-system-x86_64: unable to find CPU model 'unknown