linux-ext4 - Re: [PATCH] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl

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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 5 Jan 2008 01:12:44 +0100
From:	"Paolo Ciarrocchi" <paolo.ciarrocchi@...il.com>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Theodore Tso" <tytso@....edu>,
	"Mathieu Segaud" <mathieu.segaud@...ala.cx>,
	akpm@...ux-foundation.org, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl

On Jan 4, 2008 11:33 PM, Andi Kleen <andi@...stfloor.org> wrote:
[...]
> > I think that _one_ of the reasons that made a few people sent this kind of
> > patches to the list is because checkpatch.pl is far better then any other
> >  kerneljanitor scripts/easy task and _seems_ to be an easy way to start
> > understanding the code, creation of patches and process in general.
>
> The problem is that it has large hidden costs as pointed out. So while
> it might be easy for you it's not a cheap operation for the whole development
> process.

Isn't it a timing problem?
I mean, I guess that codying style fixes are OK if there is a good coordination
with the maintainer and patches are sent with the right timing in
order to not cause
problems in the process.
Do you agree?

May be, similar as you suggested, next time people should ask on the list
and fixing the codying style issues on the files suggested by the relevant
maintainers?

[...]
>
> How about if you're looking for simple work for a few hours you just
> send an email to l-k and ask if someone has an idea for something?
> I'm sure you'll get suggestions. Probably more than you can take.
>
> e.g. from the top of my hat what would be useful:
>
> - Go through Documentation/* files and check if the options etc. described
> in there are still in the code
>
> That will actually require you to find code in the source tree and understand
> it at least a little bit which are both very useful skills in general.
>
> - Or check for kerneldoc comments that do not appear in the kerneldoc output
> (because the files are missing in the DocBook templates)
>
> - Or build the kernel and check for any "deprecated" warnings and fix them
> [perhaps not 100% trivial, but should be doable by studying other code
> a bit -- i expect that people who attempt to write such patches have at least
> some knowledge of programming and C so that should be possible]

OK, thanks for the hints!

> > I mean, I now understand the rationales behind your complaints but I
> > don't think it's
> >  good idea to discourage people willing to perform easy task.
> > They just need guidance in order to be useful.
>
> Yes, the best way to get guidance is to ask.

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html