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 B27B343354; Fri, 17 Nov 2023 14:47:27 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 30734410EE; Fri, 17 Nov 2023 14:47:27 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 8C97540ED1 for ; Fri, 17 Nov 2023 14:47:26 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 5DC03200F4; Fri, 17 Nov 2023 14:47:26 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC 0/3] Detect superfluous newline in logs X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 17 Nov 2023 14:47:25 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F03C@smartserver.smartshare.dk> In-Reply-To: <20231117131824.1977792-1-david.marchand@redhat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC 0/3] Detect superfluous newline in logs Thread-Index: AdoZWJYQQffhLZjzR3GXJstn3ERajQAAa5gQ References: <20231117131824.1977792-1-david.marchand@redhat.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "David Marchand" , Cc: , , , 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 > From: David Marchand [mailto:david.marchand@redhat.com] > Sent: Friday, 17 November 2023 14.18 >=20 > 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. >=20 > This issue would only get noticed when actually hitting this log = (which > may be something difficult to do). >=20 > This series proposes to introduce a new RTE_LOG 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. >=20 The new helper's name is RTE_LOG_LINE, not RTE_LOG. As far as I can see, RTE_LOG continues working as before - allowing one = line of log message to span multiple lines of RTE_LOG() calls with \n in = the last of them. Which is good. Anyway, I like the concept. And it solves a real problem. If you want other names, e.g. RTE_LOG for a complete line (appending \n = in the macro itself), and RTE_LOG_PART (or similar) for an incomplete = line, I wouldn't object. But that would probably break the API. >=20 > Note: > - the first patch is intentionnally sent as a single block: splitting > it > into per library commits with correct Fixes: tags is a tedious work. > I would split it for a non RFC series. For now, it is enough to show > case the idea. > - the last patch shows how an existing log macro is converted,