From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DC2BC433E0 for ; Mon, 29 Jun 2020 13:40:12 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id B02F320786 for ; Mon, 29 Jun 2020 13:40:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pLO57bQt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B02F320786 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0C7871BEC5; Mon, 29 Jun 2020 15:40:10 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id CC9581BEB5 for ; Mon, 29 Jun 2020 15:40:07 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id v8so17083378iox.2 for ; Mon, 29 Jun 2020 06:40:07 -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=l9qjyZUC9y+xyOnHFRC3jAYEk+MaHkodXTXKSwR19Kg=; b=pLO57bQtVATN+u79w/FcksrFuA4T+tvsfxVNKMCjshNUn988l1pN/5jkkK0BYAuzpR wJoHy+2LmIeGfTE4rEQWFq5U2F9X41FZ/KQs6lxaQsBqNDEVy3DS1TAzuaR0ppVyyxMK ZeB7/Zd2vA88eIi1USR6Do6mgcgR5eqY0ZfGCarFEFX13ozBlFo6e2XLDYwbUS4r59ez ljJLbccHmd6dS6dDR1RZN9M0+r5/7lOv0k2LISREO5faM7qfDeVIqLluaXCgbUqhm/KC hC/uqImG7XPyxMCuV0VA9AuQNL6z/OctM6T3j5c7Oo8LIWIyauZ7tIxAH7dHE6JR02yi 40mA== 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=l9qjyZUC9y+xyOnHFRC3jAYEk+MaHkodXTXKSwR19Kg=; b=mdBKB0F6pAWW9Di9fkUuGBBii/u8wX6y6QpNTBz2uu2bFtqOlN1buxSp4OArJeQmce 6e5OYSVj8Klw1zhfcnw6wmddkKVlLXn+dk3DQ3FObY4Tc606PWjuxF1JOUDeVD43ZVTd yTJuv3yRezg0X+av5u0fJFf+q5Rn8MG01uTDrtntPyDTPsKBZcraN80QqrikESkr7k/e kJ4L/+g1tiSkUJTB6jVrGJ4EHo2ZQC+xVq4Af8A/YMZpKkwDUy9keykj1f9uO2YrYHyB zE51H9iJLRb58axJKwrMVfyNrS0Ujc8UJGpzyfTmPq0IlGOfkK7mrxa5n5brMdAHWMg7 IMtw== X-Gm-Message-State: AOAM532O3/s6GnOLgga8FOUvx7Nptie7OAtT4FxuW589zr16nFRxGX8Y 6rzdai+S++hQtTFIHViF1kRENWrrh6l84Nj9/TE= X-Google-Smtp-Source: ABdhPJw+dm/nqgWP6FoPLaOynS2hdy6boiRcsYHyR+v9Aap4jJOJ3X7t0Ue3qyH+8/Y9I2Lpi2k1pd3TwWJJkL6g8zA= X-Received: by 2002:a6b:b344:: with SMTP id c65mr17511350iof.123.1593438006991; Mon, 29 Jun 2020 06:40:06 -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: Mon, 29 Jun 2020 19:09:50 +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 6:07 PM Jerin Jacob wrote: > > 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? David, Waiting for your feedback on this to send the next version. If you have a strong preference for keeping declaration out macro then I will respin the v2 based on that. Let me know. > > > > > > > > > > - 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 > >