linux-kernel - Re: [PATCH] usb: make printk messges more searchable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0812101035450.2175-100000@iolanthe.rowland.org>
Date:	Wed, 10 Dec 2008 10:39:33 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Oliver Neukum <oliver@...kum.org>
cc:	Laurent Pinchart <laurent.pinchart@...net.be>,
	Wu Fengguang <fengguang.wu@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	<linux-usb@...r.kernel.org>
Subject: Re: [PATCH] usb: make printk messges more searchable

On Wed, 10 Dec 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.

The kernel is greppable in either case.  It's foolish to rigidly insist 
that long strings must not be broken.  And don't forget that some 
strings are created dynamically (with %s specifiers, for instance).  
How are you going to grep for them?

It's also worth pointing out that much of the source code in usbcore 
tends to indent continuation lines by two extra tab stops.  This isn't 
done all the time, admittedly.  But deliberately changing the code so 
that continuations use only one tab stop feels like a bad idea -- one 
extra tab stop looks too much like a nested statement.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/