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 6B516A051C; Fri, 26 Jun 2020 14:16:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4295D1BF5F; Fri, 26 Jun 2020 14:16:46 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 30D651BF5A for ; Fri, 26 Jun 2020 14:16:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593173803; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4QC4tSwrcy2gHXcoBVlFl30yMfpWvP+I4vEfi/zRn54=; b=YeVsivu74aJXVWoViy8yMJEvJ9RStTLAFwj1EWPKKnuXUHwSYynDusV+Azevq1FcipqYXA nRTeV6/RrvLuVtgYBMIabDEuQ9Y29+Cl/Am9ume8n0xVB935lQJbvUearvDZKWlWb/op6J dCwAVNwd1lTDfxgQB5ihAriPVYgQtXk= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-362-4WlQ4IBVNJSKdnSSCGkVtg-1; Fri, 26 Jun 2020 08:16:40 -0400 X-MC-Unique: 4WlQ4IBVNJSKdnSSCGkVtg-1 Received: by mail-vs1-f71.google.com with SMTP id d191so142942vsc.16 for ; Fri, 26 Jun 2020 05:16:39 -0700 (PDT) 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=4QC4tSwrcy2gHXcoBVlFl30yMfpWvP+I4vEfi/zRn54=; b=Mof8f7NxIHkNSJ542fhmvMnnt46IxC38rwIiIwBNYvBGxbJVrjbSoySC5ChDbjwBp/ rRsE+WJSeioW5ab0kTIZbfLNe0veQIvOXwR21Ou8XbLku6QiwWHHukp5B+6nJ/XDuxdh RHPh+uTRW229yUh131i04MJkjftv662vQcm+p9sZu2rdJsqZrr7SDY54ZdO77UE/KraI 5HtZ+SZI0XSeJjrVgF8/c87uP3tICnlOTeuicNnEMzeUbk+gaP+XP4sx642ETC14qZjM kxLiy5cLf31dbaxzdbva53uTnqOJ3PLNAy/ibJnky0Z9aBL85cP7hve+akeQzOg7ZXWn 7ApQ== X-Gm-Message-State: AOAM530hSY7ozqMZC5q5spDMUJoFECmGpXKO2+RZmj+adYIhMXqK/c/t V316bM5PGY90AzHuG2K6f8bMQKYCusipZc0XhhWsVu+ZAFpp/WQzdcDa7yFAKXckHRjMOLlCOQP h4Agp437e50vc3/R8H3c= X-Received: by 2002:a67:26c2:: with SMTP id m185mr2128284vsm.39.1593173799520; Fri, 26 Jun 2020 05:16:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzF0EaFT84dJu+Nb9U8r97+J87rxRQlz9tllZSzsdfQRlIyEAvi6rxE14XURIJ6AgPBINF4XpOOAw6qXtPFqlQ= X-Received: by 2002:a67:26c2:: with SMTP id m185mr2128259vsm.39.1593173799301; Fri, 26 Jun 2020 05:16:39 -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: David Marchand Date: Fri, 26 Jun 2020 14:16:28 +0200 Message-ID: To: Jerin Jacob Cc: Andrew Rybchenko , Jerin Jacob Kollanukkaran , dev , Thomas Monjalon , Olivier Matz X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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 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. > > - 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. -- David Marchand