[PATCH 001/001] drivers/staging/vt6656/main_usb.c: checkpatch warning

Joe Perches joe at perches.com
Sat Apr 1 04:27:51 UTC 2017


On Sat, 2017-04-01 at 05:08 +0100, Al Viro wrote:
> On Fri, Mar 31, 2017 at 08:52:50PM -0700, Joe Perches wrote:
> 
> > > MILD SUGGESTION: don't spell the function name out in format strings;
> > > 	"this_function: foo is %d", n
> > > might be better off as
> > > 	"%s: foo is %d", __func__, n
> > > in case you ever move it to another function or rename your function.
> > 
> > Thank you sir, may I have another.
> > 
> > checkpatch messages are single line.
> 
> Too bad... Incidentally, being able to get more detailed explanation of
> a warning might be a serious improvement, especially if it contains
> the rationale.  Hell, something like TeX handling of errors might be
> a good idea - warning printed, offered actions include 'give more help',
> 'continue', 'exit', 'from now on suppress this kind of warning', 'from
> now on just dump this kind of warning into log and keep going', 'from
> now on dump all warnings into log and keep going'.

Well, there is the possibility to have longer messages.
It's just the --terse option has to be somewhat sensible.

> And yes, I'm serious about having something like "mild suggestion" as
> possible severity - people are using that thing to look for potential
> improvements to make and 'such and such change might be useful for such
> and such reasons' is a lot more useful than 'this needs to be thus because
> it must be thus or I'll keep warning'.

I agree about checkpatch and ERROR/WARNING/CHECK vs some other wording.

https://lkml.org/lkml/2016/8/27/180
https://lkml.org/lkml/2015/7/16/568

The other thing that might help is for people to take
the warnings the script produces less seriously.

Maybe convert:

ERROR -> defect
WARNING -> unstylish
CHECK -> nitpick

or some such.



More information about the devel mailing list