From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756251AbbEVFG5 (ORCPT ); Fri, 22 May 2015 01:06:57 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:57201 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751649AbbEVFGy (ORCPT ); Fri, 22 May 2015 01:06:54 -0400 X-IronPort-AV: E=Sophos;i="5.13,474,1427752800"; d="scan'208";a="125913579" Date: Fri, 22 May 2015 07:06:47 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Michael Shuey cc: Julia Lawall , Joe Perches , "Drokin, Oleg" , devel@driverdev.osuosl.org, gregkh@linuxfoundation.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, HPDD-discuss@ml01.01.org, lustre-devel@lists.lustre.org Subject: Re: [PATCH v4 10/13] staging: lustre: lnet: lnet: checkpatch.pl fixes In-Reply-To: Message-ID: References: <1432237849-53947-1-git-send-email-shuey@purdue.edu> <1432237849-53947-11-git-send-email-shuey@purdue.edu> <1432242004.20840.68.camel@perches.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-55890910-1432271212=:2672" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-55890910-1432271212=:2672 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 21 May 2015, Michael Shuey wrote: > That's a task (of many) I've been putting on the back burner until the code > is cleaner.  It's also a HUGE change, since there are debug macros > everywhere, and they all check a #define'd mask to see if they should fire, > and the behavior is likely governed by parts of the lustre user land tools > as well. > > Suggestions are welcome.  Do other parts of the linux kernel define complex > debugging macros like these, or is this a lustre-ism?  Any suggestions on > how to handle this more in line with existing drivers? Once you decide what to do, you can use Coccinelle to make the changes for you. So you shouldn't be put off by the number of code sites to change. The normal functions are pr_err, pr_warn, etc. Perhaps you can follow Joe's suggestions if you really need something more complicated. julia > > -- > Mike Shuey > > On Thu, May 21, 2015 at 5:29 PM, Julia Lawall wrote: > > > > > > > > On Thu, 21 May 2015, Joe Perches wrote: > > > > > On Thu, 2015-05-21 at 15:50 -0400, Mike Shuey wrote: > > > > Fix many checkpatch.pl warnings. > > > [] > > > > diff --git a/drivers/staging/lustre/lnet/lnet/acceptor.c > b/drivers/staging/lustre/lnet/lnet/acceptor.c > > > [] > > > > @@ -99,38 +99,42 @@ lnet_connect_console_error(int rc, lnet_nid_t > peer_nid, > > > >     switch (rc) { > > > >     /* "normal" errors */ > > > >     case -ECONNREFUSED: > > > > -           CNETERR("Connection to %s at host %pI4h on port %d was > refused: check that Lustre is running on that node.\n", > > > > -                   libcfs_nid2str(peer_nid), > > > > -                   &peer_ip, peer_port); > > > > +           CNETERR( > > > > +                   "Connection to %s at host %pI4h on port %d was > refused: check that Lustre is running on that node.\n", > > > > +                   libcfs_nid2str(peer_nid), &peer_ip, peer_port); > > > > > > These are not improvements and checkpatch messages aren't dicta. > > > > > > Please don't convert code unless the conversion makes it better > > > for a human reader. > > > > > > These don't. > > > > I haven't looked into it, but perhaps there is a standard kernel printing > > function that these could be converted to directly? > > > > julia > > --8323329-55890910-1432271212=:2672--