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 8B0C24374F; Thu, 21 Dec 2023 10:31:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1A68140EDC; Thu, 21 Dec 2023 10:31:28 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 69693406B8 for ; Thu, 21 Dec 2023 10:31:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1703151086; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vWs4Fu8uFlrLq6YAUEW28WlBf+9PgAmkjx6IA6yqIZk=; b=B+ulRfCnRZes7L07VbzTiPl1juK92VU6CeZhUG8GEXiwrvjweoG7m7kIfzRVybhgY6Wd2z vZLW9W3IYnLyCfrC2Ds2QTr1Ti9xhmxNMds/lvps/CkhlK8XNFoONmRNhjfvS64KmHajKB /ct+UU+CEQsazxIKjmvEowyjn3XFG7E= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-626-C-vAx44YNxqSptIywm8tTQ-1; Thu, 21 Dec 2023 04:31:24 -0500 X-MC-Unique: C-vAx44YNxqSptIywm8tTQ-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-50e5aa11579so485101e87.1 for ; Thu, 21 Dec 2023 01:31:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703151083; x=1703755883; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vWs4Fu8uFlrLq6YAUEW28WlBf+9PgAmkjx6IA6yqIZk=; b=o5kguD7qCoQF5cc68JRjA405Rr0ar4ash5HpZMf+/BCDGqzYyEBudm5jBombr3IaR9 cSxavdDUusofZTvOxjZiCDkNsAHKY6WSHPPp3jrmlI7M2BiiQhgba3rNJr3lSsvVVOjf vHb+zshR+6hBvHfbagYUHVVPJvIt+MGJKLbgVTMGapEsB/9sK2IKNVTCWTtUFrXgckw3 5cP7Z1P8giD5fh8eeUwelDMylBIIFzWw3MBLn1mPiccMMZTgg6WeOcieD/u44LL2XUEj wrA3OGFFGxFxdNUMIuvMYZDvtxAk2meUmInk3E4LXyaUx2tPwW6M9GIKypJ7L8gAGNLy sOWg== X-Gm-Message-State: AOJu0YwR96T1YTcclKU2CgEO83gJHlw/QsMkerYmH1s7qyegvYh4vtrq t8k33JkIlUxAIyCs1sLhbkyDDYlDldN/p9yApz+HovFNZ3SzbsVAAso8u+1ZU2AugKJ7maastcH r51/GsV4LD9Mxx28bt1E= X-Received: by 2002:ac2:4c55:0:b0:50b:ff9c:94f2 with SMTP id o21-20020ac24c55000000b0050bff9c94f2mr12422853lfk.88.1703151083078; Thu, 21 Dec 2023 01:31:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IFfCHbRpjUreBJNrzkLReXMWPL7nrYwMfBmSM6/KXBZc5sDXi3Czw9Q8yZFM0dJpIGt2KPFbEqZ4wAlQXZsNAU= X-Received: by 2002:ac2:4c55:0:b0:50b:ff9c:94f2 with SMTP id o21-20020ac24c55000000b0050bff9c94f2mr12422846lfk.88.1703151082787; Thu, 21 Dec 2023 01:31:22 -0800 (PST) MIME-Version: 1.0 References: <20231117131824.1977792-1-david.marchand@redhat.com> <20231220153607.718606-1-david.marchand@redhat.com> In-Reply-To: <20231220153607.718606-1-david.marchand@redhat.com> From: David Marchand Date: Thu, 21 Dec 2023 10:31:11 +0100 Message-ID: Subject: Re: [PATCH v5 00/13] Detect superfluous newline in logs To: David Marchand Cc: dev@dpdk.org, thomas@monjalon.net, ferruh.yigit@amd.com, bruce.richardson@intel.com, stephen@networkplumber.org, mb@smartsharesystems.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Wed, Dec 20, 2023 at 4:37=E2=80=AFPM David Marchand wrote: > > Getting readable and consistent logs is important when running a DPDK > application, especially when troubleshooting. > A common issue with logs is when a DPDK change do not add (or on the > contrary add too many \n) in the format string. > > This issue would only get noticed when actually hitting this log (which > may be a situation hard to reach). > > This series proposes to introduce a new RTE_LOG_LINE helper that is > responsible for logging a one line message and spews a build error (with > gcc) if any \n is part of the format string. > > > Since the v1 discussion on the cover letter, I changed my mind, and made = the > choice to break existing logging helpers exported in the public API. > The reasoning is that those should not be used in the first place: > logs should be produced only by the library that registers the logtype. > > Some multiline logging for debugging and the test assert macros are > still present, but in this case an explicit call to RTE_LOG() is done. > This can be checked with a simple: > $ git grep -E 'RTE_LOG(_DP)?\(' -- lib/ :^lib/log/ > lib/acl/acl_bld.c: RTE_LOG(DEBUG, ACL, "Build phase for ACL \"%s\":\= n" > lib/acl/acl_gen.c: RTE_LOG(DEBUG, ACL, "Gen phase for ACL \"%s\":\n" > lib/bpf/bpf_validate.c: RTE_LOG(DEBUG, BPF, "%s(%p) stats:\n" > lib/bpf/bpf_validate.c: RTE_LOG(DEBUG, BPF, > lib/eal/common/eal_common_debug.c: RTE_LOG(CRIT, EAL, "Error= - exiting with code: %d\n" > lib/eal/include/rte_test.h: RTE_LOG(ERR, EAL, "Test assert %s= line %d failed: " \ > lib/ip_frag/ip_frag_common.h:#define IP_FRAG_LOG(lvl, fmt, args...) R= TE_LOG(lvl, IPFRAG, fmt, ##args) > lib/sched/rte_sched.c: RTE_LOG(DEBUG, SCHED, "Low level config for pipe = profile %u:\n" > lib/sched/rte_sched.c: RTE_LOG(DEBUG, SCHED, "Low level config for subpo= rt profile %u:\n" > lib/vhost/vhost.h: RTE_LOG_DP(DEBUG, VHOST_DATA, "VHOST_DATA: (%s) %= s", dev->ifname, packet); \ Series applied, thanks for the reviews. --=20 David Marchand