From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7662843354; Fri, 17 Nov 2023 14:48:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6180E410FB; Fri, 17 Nov 2023 14:48:42 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 0078D40ED1 for <dev@dpdk.org>; Fri, 17 Nov 2023 14:48:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700228920; 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=xIMmhWyAfDWSgr1ZsH1ekiocQhvVs1P4GVT0Br3csB0=; b=O7BE4gkufk1Q2QUU/O7tbUokEDmKfJ1KCZgd/or+dncuWlWSKIYR4L+ksbLuWMLAaTmE24 r6m0e72VH+HbJZF2UAhOzJZqpB+yWYVYkf3cTbRDqvUcbWhDQZWFc0H0/6R/cXHraY9bT0 ASXt8j9cgghCPuND2hEU7nf20Me9+RE= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-177-s3yQ9f5HPsqriDnIdNESCA-1; Fri, 17 Nov 2023 08:48:39 -0500 X-MC-Unique: s3yQ9f5HPsqriDnIdNESCA-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2c83421c6e8so20100951fa.2 for <dev@dpdk.org>; Fri, 17 Nov 2023 05:48:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700228917; x=1700833717; 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=xIMmhWyAfDWSgr1ZsH1ekiocQhvVs1P4GVT0Br3csB0=; b=pClfFW5cGRWYITa+wC8zT/CBQfOx4WkZu/9ILvLteIm8Ee9HxiY1zV6eYbzTWJxCbS mCLG/0zCRvJkGPt9fw5nBD1BCZDXgCfVaVRTvgXYrZrFYl4QVZkBUskNPnyEonK/Lz+j 5wj0ue3lxVtWPpy1XU/sYSlmoy9rBG4Cqab0633YR13VctTeuCisYBc+egSkHLEaiS+d p1kDw+Y46tMYGIeWAKoP/54v0rzwN9qzIBr6uVjnyEi+iPE+bMGnX83rnugxklZZZ6ez bvO3CbrQ/GnINk6fQm0Y432a9S4exjQMU9k/chnDjQETzqhBwySf1xkflzpRzwgC2R0w YYEw== X-Gm-Message-State: AOJu0YyvAzY67YhDCdnTTBq1f9yQ9DS0mpahO4V7jFf9cNxij4ioQSR2 ahZGkH+hCh9yxvwf7fRZ/Yuoj1eXPpBx14FIvLRj/ZJby69a8ii382DLoZYwjqD3fxktW6MrctE FX80+FLcV1n5ocxxSAgc= X-Received: by 2002:a2e:8608:0:b0:2b9:f27f:e491 with SMTP id a8-20020a2e8608000000b002b9f27fe491mr8837754lji.42.1700228917718; Fri, 17 Nov 2023 05:48:37 -0800 (PST) X-Google-Smtp-Source: AGHT+IHyP/LU2wIML9QzEavlVcyUXPjAiwwtjT9zcVy+c4vqrJ4603bg/jURvk12+6JGvHpqdZzyZXCXC/AGtDaqAgs= X-Received: by 2002:a2e:8608:0:b0:2b9:f27f:e491 with SMTP id a8-20020a2e8608000000b002b9f27fe491mr8837746lji.42.1700228917413; Fri, 17 Nov 2023 05:48:37 -0800 (PST) MIME-Version: 1.0 References: <20231117131824.1977792-1-david.marchand@redhat.com> <ZVdqLw8zQBpc6Aqu@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <ZVdqLw8zQBpc6Aqu@bricha3-MOBL.ger.corp.intel.com> From: David Marchand <david.marchand@redhat.com> Date: Fri, 17 Nov 2023 14:48:25 +0100 Message-ID: <CAJFAV8wQxzDA3CMcL43BcRoEDx5yCPeqVgffV1A5j9JACan1Kg@mail.gmail.com> Subject: Re: [RFC 0/3] Detect superfluous newline in logs To: Bruce Richardson <bruce.richardson@intel.com> Cc: dev@dpdk.org, thomas@monjalon.net, ferruh.yigit@amd.com, stephen@networkplumber.org 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org On Fri, Nov 17, 2023 at 2:27=E2=80=AFPM Bruce Richardson <bruce.richardson@intel.com> wrote: > > On Fri, Nov 17, 2023 at 02:18:21PM +0100, 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 something difficult to do). > > > > This series proposes to introduce a new RTE_LOG helper that is > > responsible for logging a one line message and spews a build error (wit= h > > gcc) if any \n is part of the format string. > > > > > > Note: > > - the first patch is intentionnally sent as a single block: splitting i= t > > 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, > > > > > very nice. I definitely think this should be implemented for 24.03 I am still wondering how this idea should evolve... Some points I have in mind but for which I am not sure what is the best. Some log helpers were exposed to applications and had no explicit requirement wrt \n. Applications may have used those helpers with multiline messages. So maybe existing *exposed* helpers should be left untouched... and a new helper would need to be introduced. IOW with an example, cryptodev (missing a RTE_ prefix) CDEV_LOG_ERR macro is publicly exposed. A CDEV_LOG_LINE_ERR may be needed to avoid breaking external users. There are a lot of other log macros that let it to the callers to add a trailing \n. Should we convert them? Converting the *whole* DPDK code to the new helper (with some exceptions for people who like multiline logs..) would be nice to close this topic once and for all. But it would likely be a nightmare for later fixes that contain logs and which could introduce regressions in such logs if the backport does not take care of re-adding a \n. --=20 David Marchand