From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752376AbbGBGFN (ORCPT ); Thu, 2 Jul 2015 02:05:13 -0400 Received: from plane.gmane.org ([80.91.229.3]:48621 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751979AbbGBGFH (ORCPT ); Thu, 2 Jul 2015 02:05:07 -0400 X-Injected-Via-Gmane: http://gmane.org/ To: linux-kernel@vger.kernel.org From: khalasa@piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=) Subject: Re: [PATCH] defines modified to match the 80-char rule Date: Wed, 01 Jul 2015 09:59:33 +0200 Message-ID: References: <1435094481-32275-1-git-send-email-mario.bambagini@gmail.com> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: nat.piap.pl Cancel-Lock: sha1:B3+92tW3iV4YpVNabZtu3swyM30= Cc: driverdev-devel@linuxdriverproject.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mario Bambagini writes: > Defines have been written in more than one line to match the 80-character > rule. This error has been fixed 6 times in this file. > The file is fully compliant with respect to the coding rules now. Rules, maybe. But is it better, i.e., more readable? > --- a/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h > +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h > @@ -233,14 +233,20 @@ do { \ > #define CNETERR(format, a...) CDEBUG_LIMIT(D_NETERROR, format, ## a) > #define CEMERG(format, ...) CDEBUG_LIMIT(D_EMERG, format, ## __VA_ARGS__) > > -#define LCONSOLE(mask, format, ...) CDEBUG(D_CONSOLE | (mask), format, ## __VA_ARGS__) > -#define LCONSOLE_INFO(format, ...) CDEBUG_LIMIT(D_CONSOLE, format, ## __VA_ARGS__) > -#define LCONSOLE_WARN(format, ...) CDEBUG_LIMIT(D_CONSOLE | D_WARNING, format, ## __VA_ARGS__) > -#define LCONSOLE_ERROR_MSG(errnum, format, ...) CDEBUG_LIMIT(D_CONSOLE | D_ERROR, \ > - "%x-%x: " format, errnum, LERRCHKSUM(errnum), ## __VA_ARGS__) > -#define LCONSOLE_ERROR(format, ...) LCONSOLE_ERROR_MSG(0x00, format, ## __VA_ARGS__) > +#define LCONSOLE(mask, format, ...) \ > + CDEBUG(D_CONSOLE | (mask), format, ## __VA_ARGS__) > +#define LCONSOLE_INFO(format, ...) \ > + CDEBUG_LIMIT(D_CONSOLE, format, ## __VA_ARGS__) > +#define LCONSOLE_WARN(format, ...) \ > + CDEBUG_LIMIT(D_CONSOLE | D_WARNING, format, ## __VA_ARGS__) > +#define LCONSOLE_ERROR_MSG(errnum, format, ...) \ > + CDEBUG_LIMIT(D_CONSOLE | D_ERROR, "%x-%x: " format, \ > + errnum, LERRCHKSUM(errnum), ## __VA_ARGS__) > +#define LCONSOLE_ERROR(format, ...) \ > + LCONSOLE_ERROR_MSG(0x00, format, ## __VA_ARGS__) > > -#define LCONSOLE_EMERG(format, ...) CDEBUG(D_CONSOLE | D_EMERG, format, ## __VA_ARGS__) > +#define LCONSOLE_EMERG(format, ...) \ > + CDEBUG(D_CONSOLE | D_EMERG, format, ## __VA_ARGS__) > > int libcfs_debug_msg(struct libcfs_debug_msg_data *msgdata, > const char *format1, ...) ... I don't think so. Perhaps if I wasn't using the bleading edge tech 132-column digital flat LCD screen, I would see this differently (Emacs isn't perfect when displaying long lines on IBM monochrome display adapter, even with the intelligent-long-lines-wrap package). -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland