From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 71147A051C; Fri, 26 Jun 2020 14:38:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 428F41BF71; Fri, 26 Jun 2020 14:38:14 +0200 (CEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id B29611BF5F for ; Fri, 26 Jun 2020 14:38:12 +0200 (CEST) Received: by mail-io1-f65.google.com with SMTP id q8so9629194iow.7 for ; Fri, 26 Jun 2020 05:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YhzYA3wt2/r/q3yCcGZEnotkrgbIzq3BEvsDWjNPII4=; b=Ycjflr65ARmNS3oR9vi8HmcMgp9yF+CdGVXhySxqQQxbzGBA3H0x44TsvPseTp86qt +EHD4xP3X24J41U6SkE6lvneRB4ox0gJNkhYD1q0LwTxqKswkvUWnevmct+EMDRoT/k3 3gNcjYoTq87KpfIJovyjseiRWhhJc5lV/7cS41va5EvZyv6TCXXmXf5Xavy/sH+ubkOr vwRH1kx2PRcZ38hO8AGYqF+IYPmC4fwEMrLc2sZnmUqb7jwVWeNalcdXen5le5sPDsqA XFdwmeDrCoLPVWDIyRVmKZmZG64y01xFoZzk1OTcwcHgMHIlL/lGAwURSgom7646krlS UGog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YhzYA3wt2/r/q3yCcGZEnotkrgbIzq3BEvsDWjNPII4=; b=mKs0yB5zRIHBf6q8tUMlx6x7OTMUG4oCs9M8r4N9dsdXwSRCxhOWgm7M07EuiKYBxK yOVAHtpyX1c2aKNxtd0FRZoAu9NPjWaY0xaerbkJZcVNGuKPnv0sszvmq5YWrj/jtLxB CP0msoyPnd64Jb7bEE3ADc99Jc3kLfGw6hLOdmllzTFk4qsJQrNa8mfom6I93tceSWlE Gq8/cjEkKmgCiTb4bdcmyvzEZJlrUYQ9EP0yzH0UKeV58Bi22ZkO9q2WXVsVUcmKjCiu lDyr/vxOqxETcTJqAF5uZlAuQvrZPfGLbRj3TdwcRKrWqDDfZgthFHgWKDbRlupwKvSh 41VQ== X-Gm-Message-State: AOAM5324izpR+c0yLtlibz/b2EHbhhM8DQoa2xf0yawOnMyNrNk/hkd+ zopJthUXONjpPiX57fqIq5lASrlrw3elZYAPxJQ= X-Google-Smtp-Source: ABdhPJymAQF+O+W4jf3pKdFnbf9WE56cDS/+xJhs3oOq0+9zF4knNRHIh7N9jjU4g5JeAYu5zxYGS6kFAdaOY2PC9qQ= X-Received: by 2002:a6b:b344:: with SMTP id c65mr3294288iof.123.1593175091801; Fri, 26 Jun 2020 05:38:11 -0700 (PDT) MIME-Version: 1.0 References: <20200617063047.1555518-1-jerinj@marvell.com> <20200617063047.1555518-2-jerinj@marvell.com> <4becf100-7f0f-d051-a40c-3944e101381a@solarflare.com> <11e13bf9-8400-50de-4638-cdd1286915e4@solarflare.com> In-Reply-To: From: Jerin Jacob Date: Fri, 26 Jun 2020 18:07:55 +0530 Message-ID: To: David Marchand Cc: Andrew Rybchenko , Jerin Jacob Kollanukkaran , dev , Thomas Monjalon , Olivier Matz Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 01/13] eal/log: introduce log register macro 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jun 26, 2020 at 5:46 PM David Marchand wrote: > > On Fri, Jun 26, 2020 at 2:06 PM Jerin Jacob wrote: > > > > On Fri, Jun 26, 2020 at 5:13 PM David Marchand > > wrote: > > > > > > On Fri, Jun 26, 2020 at 1:16 PM Jerin Jacob wrote: > > > > > > Alternative is to keep variable declaration outside, > > > > > > as David suggested, and I tend to agree that it is a > > > > > > bit better. Macro name says 'register'. It is not > > > > > > 'declare and register'. Also it avoids static-vs-extern > > > > > > problem completely. The solution allows to keep the > > > > > > variable declaration untouched and put constructor (macro) > > > > > > at the end of fine where constructors typically reside. > > > > > > > > > > My only concern with that approach is that, We can not save a lot of > > > > > code duplication > > > > > with that scheme. ie. it is [1] vs [2]. We can change the MACRO name > > > > > accordingly if that is a concern. Any suggestions? > > > > > > > > > > Let me know your preference on [1] vs [2], I will stick with for the > > > > > next version. > > > > > > > > If there are no other comments, I change RTE_LOG_REGISTER to static version > > > > and RTE_LOG_REGISTER_EXTERN for a non-static version and send the next version. > > > > > > - Having a macro that does more than what its name tells is inconvenient. > > > > I agree. What could be that name if we want to declare and register? > > RTE_LOG_DECLARE_AND_REGISTER_EXTERN? > > (sorry, gmail ctrl+enter ...) > > Or no declaration in macro and leave code as it is. Just to understand, Is it some general coding standard? or Just a preference. I dont see something like that in the Linux kernel. In this patch, http://patches.dpdk.org/patch/69681/, You are proposing the declaration in macro. See: RTE_TRACE_POINT_REGISTER I dont see anything wrong with that. Do you have technical rationale for the above rule? > > > > > - Having components set log levels at init time in the macro is a bug to me. > > > This has been worked around with > > > rte_log_register/rte_log_register_and_pick_level but the initial > > > problem is that rte_log_set_level* should only be called by the user. > > > > I agree with the below stuff, That's is not introduced by this patch. > > It is already there. > > Be it macro or no macro code. > > > > I think this patch helps to change to new scheme as it takes care of > > changing the > > registration part to commonplace so that we can set to the same level > > in the future if > > everyone agrees to it > > We will still expose this macro meaning that we will have an API breakage later. > So if we go with introducing this, let's make it good from the start. But Is everyone OK with removing the "level" from the register before we think about breaking the API later?. I see PMD uses multiple levels in the same PMD for different purposes. > > > -- > David Marchand >