Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2135203ybe; Sat, 14 Sep 2019 08:28:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqwfG/tVRlWJBGSawtVUziKsIQe3Jidu2Vc4aB1HJtYzEnqopvutOThoWye1phBna73JDfTb X-Received: by 2002:a17:906:7a0d:: with SMTP id d13mr44412690ejo.242.1568474887995; Sat, 14 Sep 2019 08:28:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568474887; cv=none; d=google.com; s=arc-20160816; b=zVLOFHIemcJ5jLkfPQvo0TFA7urQ/ZuLLMa5yZWSjU58sMNhn/+ZB4jOo8owh/Pb95 1aT4uieWyCURONXKxO8YL5w9s32rTHcwSvGaqYhMXjND+Xj/pdn0kO20MkDYYhGoHlwI p4VLoJbtMMXjIB7hwvO9P7Husv6jrTVwhnIbQWbMwvINvZgvDd9hRJ2kEk+Z84viN3gU wuuzjLpwA4t41NhHg+sXkpxxHycB11p4xW2+rcOQ711dJ232tzJ4kfgHCHhUmHHpDvMr CzwXyQ7Ih1ksoMozqzcpg14yo3E4tTTgozAHbtGTKRe1wWK3Dsg9+84AyM9INfiFYaEF AIXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=x4jbTlTLiUpvrZXcSofyMWxU76tD7S8ngWeT6+lgHw0=; b=KmKsVd+nG4qSZLlMYUMimTx7El/wiBIHiZGNHqPC44HGl7LEl2An6MDCJqiletEs9I EANNPES8SCNhkgcw2tl+xeFTReCW3eJgGmMSPp93GA7SuLMYecO7xCkEQuk46h88bJQd 2mFwjN4yfegJVHRqtpVAiH+HfipzBk5TbLTYM5OL760s6aHUST7Cjx5MsthDBVUqdpBi Qh0kYjvqCNBkmYpq9NuuOX4vzo0S4kw//41RAP3fjapiiCF24uU8DavKl3lPIJ0vrd2G MErddzARG+ZVaP06ccK4/DfNY1/isZ+JgqeaoCe/nTgZKWtHV6JTK6v4AEJQRDtWsj6z YpwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gy21si1294895ejb.371.2019.09.14.08.27.44; Sat, 14 Sep 2019 08:28:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727258AbfINHuZ (ORCPT + 99 others); Sat, 14 Sep 2019 03:50:25 -0400 Received: from ms.lwn.net ([45.79.88.28]:35640 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726622AbfINHuZ (ORCPT ); Sat, 14 Sep 2019 03:50:25 -0400 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 9E15E378; Sat, 14 Sep 2019 07:50:22 +0000 (UTC) Date: Sat, 14 Sep 2019 01:50:18 -0600 From: Jonathan Corbet To: =?UTF-8?B?QW5kcsOp?= Almeida Cc: linux-block@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, axboe@kernel.dk, kernel@collabora.com, krisman@collabora.com Subject: Re: [PATCH v2 4/4] coding-style: add explanation about pr_fmt macro Message-ID: <20190914015018.4fa90f28@lwn.net> In-Reply-To: <20190913220300.422869-5-andrealmeid@collabora.com> References: <20190913220300.422869-1-andrealmeid@collabora.com> <20190913220300.422869-5-andrealmeid@collabora.com> Organization: LWN.net X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 13 Sep 2019 19:03:00 -0300 André Almeida wrote: > The pr_fmt macro is useful to format log messages printed by pr_XXXX() > functions. Add text to explain the purpose of it, how to use and an > example. So I've finally had a chance to take a real look at this... > diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst > index f4a2198187f9..1a33a933fbd3 100644 > --- a/Documentation/process/coding-style.rst > +++ b/Documentation/process/coding-style.rst > @@ -819,7 +819,15 @@ which you should use to make sure messages are matched to the right device > and driver, and are tagged with the right level: dev_err(), dev_warn(), > dev_info(), and so forth. For messages that aren't associated with a > particular device, defines pr_notice(), pr_info(), > -pr_warn(), pr_err(), etc. > +pr_warn(), pr_err(), etc. It's possible to format pr_XXX() messages using the > +macro pr_fmt() to prevent rewriting the style of messages. It should be > +defined before ``#include ``, to avoid compiler warning about > +redefinitions, or just use ``#undef pr_fmt``. This is particularly useful for > +adding the name of the module at the beginning of the message, for instance: > + > +.. code-block:: c > + > + #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt Honestly, I think that this is out of scope for a document on coding style. That document is already far too long for most people to read, I don't think we should load it down with more stuff that isn't directly style related. That said, the information can be useful. I wanted to say that it should go with the documentation of the pr_* macros but ... well ... um ... we don't seem to have a whole lot of that. Figures. I suspect this is more than you wanted to sign up for, but...IMO, the right thing to do is to fill printk.h with a nice set of kerneldoc comments describing how this stuff should be used, then to pull that information into the core-api manual, somewhere near our extensive discussion of printk formats. It's amazing that we lack docs for something so basic. Thanks, jon