linux-kernel - Re: [PATCH] staging: media: lirc: lirc_zilog.c: fix quoted strings split across lines

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]

Date:	Tue, 25 Nov 2014 17:49:40 -0800
From:	Joe Perches <joe@...ches.com>
To:	Luis de Bethencourt <luis@...ethencourt.com>
Cc:	linux-kernel@...r.kernel.org, jarod@...sonet.com,
	m.chehab@...sung.com, gregkh@...uxfoundation.org,
	mahfouz.saif.elyazal@...il.com, dan.carpenter@...cle.com,
	tuomas.tynkkynen@....fi, gulsah.1004@...il.com,
	linux-media@...r.kernel.org, devel@...verdev.osuosl.org
Subject: Re: [PATCH] staging: media: lirc: lirc_zilog.c: fix quoted strings
 split across lines

On Tue, 2014-11-25 at 21:14 +0000, Luis de Bethencourt wrote:
> On Tue, Nov 25, 2014 at 01:00:07PM -0800, Joe Perches wrote:
> > In the future, you might consider being more
> > comprehensive with your patches.
> 
> Wasn't sure about the scope of the style fixing
> patches. I've been reading Kernel Newbies and
> this looked like a good way to start
> contributing. Good to know more exhaustive
> changes are welcome.
> > 
> > This code could be neatened a bit by:
> > 
> > o using another set of logging macros
> > o removing the unnecessary ftrace like logging
> > o realigning arguments
> 
> Great ideas.
> Should this have been all included in one patch,
> or each as part of a series with the previous
> one?
> Want to take the opportunity to learn about the
> process.

Hello again Luis.

I think the suggestion I posted here is suitable
for a single change.

Ideally, you'd make individual patches each with
a single "type" of change.

There is a script I posted a while back that
groups various checkpatch "types" together and
makes it a bit easier to do cleanup style
patches.

https://lkml.org/lkml/2014/7/11/794

But don't just use checkpatch as the sole
decider of what's appropriate to fix or neaten.

checkpatch is a stupid, brainless little script.
So is the automation script that uses checkpatch.

For instance, checkpatch would not have suggested
creating and using another logging macro.

Please use your own taste to best figure out what
to fix and how.

Using checkpatch to get familiar with kernel
development is fine and all, but fixing actual
defects and submitting new code is way more
useful.

cheers, welcome, Joe

--
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/