On Tue, 07 Apr 2015 07:26:13 -0700 Joe Perches <j...@perches.com> wrote:
> On Tue, 2015-04-07 at 10:10 -0400, Steven Rostedt wrote: > > On Tue, 07 Apr 2015 07:01:37 -0700 > > Joe Perches <j...@perches.com> wrote: > > > > > o Please add a test for $realfile !~ m@kernel/trace/@ > > > or maybe $realfile !~ /(?:trace|tracing)/ > > > o ERROR seems a bit strong, WARN is probably good enough > > > > I'm thinking ERROR is good. There's no reason to have it. In fact, you > > must never have it. Looking at the other ERROR() conditions, I say this > > Look at trace_printk in fs/ext4/inline.c > Yeah, I've stumbled on that one before and looked and said to myself "WTF". But as it is masked around DEBUG, I let it slide. I still don't like it, because it really should be a tracepoint instead. The problem with trace_printk(), is that it is either all on or all off. You can not pick and choose, and they clutter the trace. I may send patches to remove that anyway. > It's in a section guarded by a CONFIG_FOO_DEBUG > block. Is the use there an error? Perhaps not > and I think it better if checkpatch ERROR messages > are more definitive. > > > is just as strong and perhaps even stronger. You have ERROR() for > > trailing white space. This is much worse than that. > > I'm not much of a fan of that one, nor of most > of the ERROR uses in checkpatch actually. > > I think it might be better if all of the checkpatch > whitespace/style related messages were WARN not ERROR. I agree. I still rather have this be an ERROR and not a WARN, because I rather avoid even those that encapsulate it with CONFIG_FOO_DEBUG. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/