[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54C67933.5050304@suse.cz>
Date: Mon, 26 Jan 2015 18:28:19 +0100
From: Jiri Slaby <jslaby@...e.cz>
To: Eric Sandeen <sandeen@...hat.com>,
Jan Mrazek <email@...zamrazek.cz>,
Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org,
trivial@...nel.org
Subject: Re: [PATCH 1/1] Fix of coding style
On 01/26/2015, 06:18 PM, Eric Sandeen wrote:
> On 1/26/15 10:24 AM, Jan Mrazek wrote:
>> - multiline strings changed to singleline (so it can be greped)
>
> Thereby blowing past 80 columns in many cases, something we generally
> don't like to do, per Documentation/CodingStyle:
When you refer to that document, you certainly read the whole chapter 2 :).
>> The limit on the length of lines is 80 columns and this is a strongly
>> preferred limit.
>
> I'm not so sure about the grep-ability value, because nobody's going to
> grep for "...%s): %s:%d: inode #%lu: ..." anyway...
Perhaps, but
grep EXT4.*block.*comm
does the trick quite nice... And this is actually a nice example of the
point of this exercise.
> but if it's really deemed desirable to keep these strings on one line,
> we could do i.e.:
>
>> + printk(KERN_CRIT
>> +"EXT4-fs error (device %s): %s:%d: inode #%lu: block %llu: comm %s: %pV\n",
>> inode->i_sb->s_id, function, line, inode->i_ino,
>> block, current->comm, &vaf)
>
> which is a trick the xfs code uses in some places.
Oh no, that's ugly. If anything, this could have been pr_crit("EXT4-fs
error ...
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists