linux-kernel - Re: [PATCH 2/9] ext4: Use pr_fmt and pr

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]

Message-ID: <4F684673.1050309@suse.cz>
Date:	Tue, 20 Mar 2012 09:57:23 +0100
From:	Jiri Slaby <jslaby@...e.cz>
To:	Joe Perches <joe@...ches.com>
CC:	Jiri Slaby <jirislaby@...il.com>, Ted Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/9] ext4: Use pr_fmt and pr_<level>

On 03/19/2012 06:09 PM, Joe Perches wrote:
> On Mon, 2012-03-19 at 17:46 +0100, Jiri Slaby wrote:
>> On 03/19/2012 05:25 AM, Joe Perches wrote:
>>> On Mon, 2012-03-19 at 00:09 -0400, Ted Ts'o wrote:
>>>> One evidence that this patch is noise is that it doesn't apply cleanly
>>>> just on top of my current patch set that I plan to send to Linus.
>>> It's more evident that you don't make
>>> public your own internal patch queue
>>> quickly enough than anything else.
>> Please stop repeating that shit. I already explained you the reasons. A
>> couple of weeks ago.
...
> As far as I can tell, your "reasons" as you
> explained it is that you just do not like
> whitespace or style changes.

No, sorry, you misunderstand me. Here, I meant your complain that we are
not fast enough with pushing patches. Some of us simply do not push
patches as soon as they are written. I personally prefer deferring
patches for some time (weeks) to actually give some testing to the
changes. Simply because I have bad experiences with patches emerging in
the (-next) tree immediately. (And I mean not only my patches.)

While you are pointing to whitespace cleanup of whole subtrees. Yes, I
wrote about _whitespace_ cleanup in the thread you are referring to. But
this can be generalized to an arbitrary cleanup. I.e. changes which do
not change functionality in no way. And that is doubtful with pr_*
changes. But as you can see in my post a couple of minutes ago, maybe I
am just missing the point of the new interface. (And I hate naming of
the pr_* functions.)

And BTW setting the argument that it is a newer interface (that is what
ath5k pr_* conversion patches commit log says) is not a good
justification at all.

thanks,
-- 
js
suse labs
--
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/