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 1B3C0A0350; Tue, 30 Jun 2020 16:43:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9BF031BFE5; Tue, 30 Jun 2020 16:43:15 +0200 (CEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id 379471BFCD for ; Tue, 30 Jun 2020 16:43:14 +0200 (CEST) Received: by mail-il1-f195.google.com with SMTP id w73so6080669ila.11 for ; Tue, 30 Jun 2020 07:43:14 -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=H1yLBe+B4tFe59YpvoU7tsjXkcs3Q3MbChubk1bs/gY=; b=tdV7bLji1Xe75znBIFBHkPz0dIjvJskubR1k36XvDAiJUpTuvICwDvPgaojlEr+LWY W4uZ2CxtaNorxOayeP5FJxdnClkqhBCxVX7cg3THXw6BuuTiVizHBPp97NYcqRWjGfb9 Qzba5fMMjhlffIceXU738NOt/V59yeGcW5WRv/r48lG5RT4QVXVkwx+TSS5W0d2RijgV xwcQgnMUjMy37cqwCWU/fVIPtUBIckt5h0VcTi5Ixjl4+4QF9XngWqW9agVBu/o56HtB MBeTcMXBd4XN5vF0LHSaTokOlP60KpOlBgpFmLnSY3kJ43+qDV+z4lIAgRIoQYsPO1pe 6mXw== 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=H1yLBe+B4tFe59YpvoU7tsjXkcs3Q3MbChubk1bs/gY=; b=h1qCiG734Oq/8wzg6Dg7qsSyVrvxNSzYbWBy2G5s1KB+eePbbCeuqtOB8eCQo9ukFL oY1j9Mk6gnQqVKZk6QZO8Wr1/zo9cHqyKfY1mGmssOBRUncz1dhfLHI5rSEwJSZdRuWC w4S7qjYoIXtVtZ3lZjSvTUpnWYnehPAIb9Cf1miTHsm2Sb1IL9CGhXWqo2ze8BLPpZIS 5qDTRRH67oAwp7Pjgtmtgbn0DZDip7hD5R6A+DyqPIAdjnxqMOKpcrZFXD4TXHEsKCAY wWKsfEGlZogvIKjBml2rSPm3EsHUI3uf8K6UX0Df85Nidypb4rtCOTAZ+GsIsE0hfOxC FZzA== X-Gm-Message-State: AOAM531MInH4StFMHubswu2AWwgRUXitVxap4SW53SGjby+mA8Ln3zLf bKeUG+v8+jc7lC8OBklgcT2rIbbdT3Ac2gBUwqk= X-Google-Smtp-Source: ABdhPJzq77BbSW0nhe0l6lyEKovYDacGOkbygFtcNfOJCF0H0sGZ0MONOZn/KcHi40X4Mk2uiP99A/8IRdcexh7fhAk= X-Received: by 2002:a92:d01:: with SMTP id 1mr2974891iln.294.1593528188868; Tue, 30 Jun 2020 07:43:08 -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: Tue, 30 Jun 2020 20:12:52 +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 Tue, Jun 30, 2020 at 7:09 PM David Marchand wrote: > > On Fri, Jun 26, 2020 at 2:38 PM Jerin Jacob wrote: > > > Or no declaration in macro and leave code as it is. > > > > I dont see anything wrong with that. Do you have technical rationale > > for the above rule? > > Avoid global symbols when unneeded. > Global symbols can be hidden with shared build, but that's not the > case with static build. > > This is why we try to maintain a namespace for DPDK api. > > For logtypes, a lot of those are already global and nobody complained > about them (lucky ?). > > With this patch, the static ones, that we would convert to global > symbols, are the following: > drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c:static int > fpga_5gnr_fec_logtype; > drivers/baseband/fpga_lte_fec/fpga_lte_fec.c:static int fpga_lte_fec_logtype; > drivers/baseband/null/bbdev_null.c:static int bbdev_null_logtype; > drivers/baseband/turbo_sw/bbdev_turbo_software.c:static int > bbdev_turbo_sw_logtype; > drivers/net/af_packet/rte_eth_af_packet.c:static int af_packet_logtype; > drivers/net/af_xdp/rte_eth_af_xdp.c:static int af_xdp_logtype; > drivers/net/kni/rte_eth_kni.c:static int eth_kni_logtype; > drivers/net/null/rte_eth_null.c:static int eth_null_logtype; > drivers/net/pcap/rte_eth_pcap.c:static int eth_pcap_logtype; > drivers/net/ring/rte_eth_ring.c:static int eth_ring_logtype; > drivers/net/softnic/rte_eth_softnic.c:static int pmd_softnic_logtype; > drivers/net/vdev_netvsc/vdev_netvsc.c:static int vdev_netvsc_logtype; > drivers/net/vhost/rte_eth_vhost.c:static int vhost_logtype; > drivers/vdpa/ifc/ifcvf_vdpa.c:static int ifcvf_vdpa_logtype; > lib/librte_bbdev/rte_bbdev.c:static int bbdev_logtype; > lib/librte_cfgfile/rte_cfgfile.c:static int cfgfile_logtype; > lib/librte_eventdev/rte_event_timer_adapter.c:static int evtim_logtype; > lib/librte_eventdev/rte_event_timer_adapter.c:static int evtim_buffer_logtype; > lib/librte_eventdev/rte_event_timer_adapter.c:static int evtim_svc_logtype; > lib/librte_pdump/rte_pdump.c:static int pdump_logtype; > > All of them follow some kind of convention of finishing with _logtype. > Is this enough and we won't trigger link issues in existing applications? > Probably not possible to tell. > > There was a similar discussion with Gaetan in the pci bus code, and so > far we are still in this status quo for global symbols. > > So ok, let's go with this embedded global symbol. OK. > If we hit an issue with static linking, we will need a tree-wide cleanup. > > > > > > > - 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. > > It is an API fix to me, as there should be no place for "level" interpretation. > > > Just a note, a v2 would be necessary for the > rte_log_register_type_and_pick_level use in any case. I will send v2 with rte_log_register_type_and_pick_level change and rebase to ToT. > > -- > David Marchand >