linux-kernel - Re: First kernel patch (optimization)

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:	Mon, 28 Sep 2015 03:54:20 -0300
From:	Thiago Farina <tfransosi@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	"Theodore Ts'o" <tytso@....edu>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: First kernel patch (optimization)

On Sat, Sep 19, 2015 at 2:18 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Fri, Sep 18, 2015 at 10:26:24PM -0400, Theodore Ts'o wrote:
>> On Fri, Sep 18, 2015 at 12:42:48AM -0700, Greg KH wrote:
>> > So don't take cleanup patches for your code, that's fine, and I totally
>> > understand why _you_ don't want to do that.  But to blow off the effort
>> > as being somehow trivial and not worthy of us, that's totally missing
>> > the point, and making things harder on yourself in the end.
>>
>> It's not that I think cleanup patches are "trivial and not worthy of
>> us", although I'll note that cleanup patches can end up causing real
>> bug fixes (including possibly fixes that address security problems) to
>> not apply to stable kernels, which means someone needs to deal with
>> failed patches --- or what is much more likely, the failed patch gets
>> bounced back to the overworked maintainer who then drops the patch
>> because he or she doesn't have the bandwidth to manually backport the
>> patch to N different stable trees, and then we all suffer.  So cleanup
>> patches *do* have a cost.
>
> All patches have a "cost", and that cost is something that you have to
> deal with as a maintainer.  Nothing new here at all, and if you don't
> like cleanup patches, great, don't take them.  But never go around
> saying that people should NOT send cleanup patches to subsystems you
> don't maintain like you did.  That's rude and unhelpful to everyone
> involved.
>
> The best way to ensure that you never get whitespace patches, is to
> clean your subsystem up.  And frankly, it needs a lot of work, have you
> run checkpatch on it in a while?  You could resolve this issue for
> yourself with a simple afternoon's worth of work.  Why you don't do so
> is a mystery to me.
I think what Theodore was just trying to say is that there are much more
important and pressuring things to do in the kernel (that helps our society)
then doing cleanup patches (what you will tell to your interviewer? That you
fixed the spelling of a word or removed the whitespaces of a source file?).
I think he is just pushing for a more substancial work, that fixes a crash,
improves performance, fixes a subtle bug in some important driver, fixes a
memory leak, etc.

And many maintainers of open source projects that I know off, are not
very welcome
to cleanup patches, especially when the project is mature. They just
call it churn and
turn it down.

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