public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Laurent Pinchart <laurent.pinchart@skynet.be>
Cc: Oliver Neukum <oliver@neukum.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] usb: make printk messges more searchable
Date: Wed, 10 Dec 2008 20:58:46 +0800	[thread overview]
Message-ID: <20081210125846.GC6772@localhost> (raw)
In-Reply-To: <200812101059.01068.laurent.pinchart@skynet.be>

On Wed, Dec 10, 2008 at 11:59:00AM +0200, Laurent Pinchart wrote:
> On Wednesday 10 December 2008, Oliver Neukum wrote:
> > Am Mittwoch, 10. Dezember 2008 10:42:17 schrieb Laurent Pinchart:
> > > Hi Wu,
> > >
> > > On Wednesday 10 December 2008, Wu Fengguang wrote:
> > > > Make USB printk messages long and straightforward.  One of these
> > > > decorated USB error messages cost me some smart efforts to locate.
> > >
> > > That would make the code break the 80 columns limit.
> > >
> > > From "Documentation/CodingStyle":
> > >
> > > "The limit on the length of lines is 80 columns and this is a strongly
> > > preferred limit."
> >
> > Too rigid an application is bad. The kernel must be greppable.
> 
> I've also been bitten by split strings when grepping kernel source code. A 
> cgrep that would unsplit strings before searching them would be nice :-)

Such printk will sure bite more people.  And it's amazing that the CodingStyle
document uses printk as an 80-column example:

 80 The limit on the length of lines is 80 columns and this is a strongly
 81 preferred limit.
 82 
 83 Statements longer than 80 columns will be broken into sensible chunks.
 84 Descendants are always substantially shorter than the parent and are placed
 85 substantially to the right. The same applies to function headers with a long
 86 argument list. Long strings are as well broken into shorter strings. The
 87 only exception to this is where exceeding 80 columns significantly increases
 88 readability and does not hide information.
 89 
 90 void fun(int a, int b, int c)
 91 {
 92         if (condition)
 93                 printk(KERN_WARNING "Warning this is a long printk with "
 94                                                 "3 parameters a: %u b: %u "
 95                                                 "c: %u \n", a, b, c);
 96         else
 97                 next_statement;
 98 }


  reply	other threads:[~2008-12-10 13:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-10  7:29 [PATCH] usb: make printk messges more searchable Wu Fengguang
2008-12-10  9:42 ` Laurent Pinchart
2008-12-10  9:56   ` Oliver Neukum
2008-12-10  9:59     ` Laurent Pinchart
2008-12-10 12:58       ` Wu Fengguang [this message]
2008-12-10 15:39     ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081210125846.GC6772@localhost \
    --to=fengguang.wu@intel.com \
    --cc=gregkh@suse.de \
    --cc=laurent.pinchart@skynet.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oliver@neukum.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox