From patchwork Thu Sep 12 08:26:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Marchand X-Patchwork-Id: 1345 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 B60D94596C; Thu, 12 Sep 2024 10:26:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B8BA4029F; Thu, 12 Sep 2024 10:26:55 +0200 (CEST) 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 AFD8F4025E for ; Thu, 12 Sep 2024 10:26:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1726129613; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UV6BMUKFl5g5v1WgGkW6WvLHgnZ/K7ySYkLpQThVcM4=; b=VtEb1B/P2xNrsPMlMAOjhfSTiAkvfsomd0E8RZ380MiMM0OBwiHKzAZq6X1rjLjotOCfor gnf9qusTcozENTamIht5inxgU/BSSyswUla7wpxY2T9E+QyRqiMN1OFMyOFXv8lgN+tr25 oOG40x/ihPOjPXbh1AwXoX3Lvun+gQE= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-42-d_j_ogDyONCUb9itgKvl8w-1; Thu, 12 Sep 2024 04:26:51 -0400 X-MC-Unique: d_j_ogDyONCUb9itgKvl8w-1 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (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 mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C931D195394A for ; Thu, 12 Sep 2024 08:26:50 +0000 (UTC) Received: from dmarchan.redhat.com (unknown [10.45.224.230]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 9C2D71956086 for ; Thu, 12 Sep 2024 08:26:49 +0000 (UTC) From: David Marchand To: dev@dpdk.org Subject: [PATCH v2 00/14] Use RTE_LOG_LINE in drivers Date: Thu, 12 Sep 2024 10:26:26 +0200 Message-ID: <20240912082643.1532679-1-david.marchand@redhat.com> In-Reply-To: <20240907145433.1479091-1-david.marchand@redhat.com> References: <20240907145433.1479091-1-david.marchand@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 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 This is a continuation of the cleanup effort in logging macros. As a reminder of what this series is about, RTE_LOG_LINE() has been introduced to check that the format string does not contain a trailing \n. The goal was to prevent from: - introducing multilines log messages (ugly and unhelpful for lambda users), - introducing double \n in logs, - introducing missing \n in logs, I have built/maintained this series for fixing drivers/ since the beginning of the year and I hope we can merge this series early in 24.11. Some drivers are not converted because of multiple inconsistencies. Those may be fixed later. As for the changes on lib/, new macros have been introduced so that backports trigger a build error and force the backport to adjust the patches containing logs accordingly. Most of the changes have been done with some scripting, but it is likely there are some errors and I hope driver maintainers will review in depth. A check is added for drivers/ in the hope that new drivers don't introduce more mess. Yet, sometimes it is not possible to fix macros (a good example is base/ drivers code...), so the check skips *osdep.h headers where calls to RTE_LOG() may be accepted.