From patchwork Wed Dec 20 15:35:53 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Marchand X-Patchwork-Id: 506 Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AD03843728; Wed, 20 Dec 2023 16:37:47 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6F8E940291; Wed, 20 Dec 2023 16:37:47 +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 77E054021F for ; Wed, 20 Dec 2023 16:37:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1703086665; 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=QYEEhAdrxlm6jX1nDLeVS3dHdOMMLP3DDEjeclY0FsA=; b=FOshWYW+fNvfV6rRWEEjDIPriBkF4rWvX4ONILAlxwmNUy21VH4v4BrASqCdkWBIwhnNO8 Dv470oxUSr0Lap2Z0AX2jNPyXmnoGaTdVawfzPXvnWgKE88RGT6Cxa3EXcUBIRPHSm35yA 6Ati0kWaEVlx7y5z0QHDbj+ixzdC5mQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-504-QqMLTcGtNyixhkxdf_4dXA-1; Wed, 20 Dec 2023 10:37:42 -0500 X-MC-Unique: QqMLTcGtNyixhkxdf_4dXA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 30D2E185A780; Wed, 20 Dec 2023 15:37:42 +0000 (UTC) Received: from dmarchan.redhat.com (unknown [10.45.224.218]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9BECA1C060AF; Wed, 20 Dec 2023 15:37:40 +0000 (UTC) From: David Marchand To: dev@dpdk.org Cc: thomas@monjalon.net, ferruh.yigit@amd.com, bruce.richardson@intel.com, stephen@networkplumber.org, mb@smartsharesystems.com Subject: [PATCH v5 00/13] Detect superfluous newline in logs Date: Wed, 20 Dec 2023 16:35:53 +0100 Message-ID: <20231220153607.718606-1-david.marchand@redhat.com> In-Reply-To: <20231117131824.1977792-1-david.marchand@redhat.com> References: <20231117131824.1977792-1-david.marchand@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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 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...) RTE_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 subport profile %u:\n" lib/vhost/vhost.h: RTE_LOG_DP(DEBUG, VHOST_DATA, "VHOST_DATA: (%s) %s", dev->ifname, packet); \ Changes since v4: - fixed build with -pedantic, - reworked patch 12 so it introduce new logging helpers (like for rcu), - moved the transition to RTE_LOG_LINE previously in patch 12 to the last patch of this v5 series, Changes since v3: - fixed some checkpatch complaints, Changes since RFC v2: - sent as non RFC, - fixed format string crossing line boundaries, - avoided potential collision with BPF_ namespace, Changes since RFC v1: - rebased after Stephen log changes, - added more fixes as I was making progress on the topic, - added a check so dpdk developers stop using RTE_LOG(), - added preparation patches, like "lib: replace logging helpers", - converted all libraries, keeping some special cases with explicit calls to RTE_LOG,