linux-kernel - Re: [patch 00/46] High resolution timer / dynamic tick update

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:	Wed, 24 Jan 2007 13:23:32 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...l.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Arjan van de Veen <arjan@...radead.org>,
	Roman Zippel <zippel@...ux-m68k.org>
Subject: Re: [patch 00/46] High resolution timer / dynamic tick update

On Wed, 2007-01-24 at 12:51 -0800, Daniel Walker wrote:
> On Wed, 2007-01-24 at 11:57 -0800, john stultz wrote:
> > Thomas' changes are more obviously purpose driven, and Daniel's appear
> > more like just cleanups. So given that, if it were me, I'd put Thomas
> > changes in first, and re-diff Daniel's non-redundant changes on top.
> 
> Seems backwards , clean ups should always go first. If Thomas had
> started off my patch set his changes would have been smaller and
> hopefully stronger. (I even remember you tell me that you wanted the
> kernel/time/timekeeping.c change first in my series cause clean ups
> should go first..)

Well, I suggested the kernel/time/timekeeping.c change go in last cycle,
when you pushed your other cleanups, because that sort of large,
move-tons-of-code patch sucks to keep out of the tree for long as it
would surely collide with something at some point.

> If the HRT changes went in I would have to re-make my cleanups, then do
> more cleanup to change the stuff Thomas is introducing. Looking at his
> code, to do a clean up I would want to just outright revert it.
[snip]
> Given the circumstances I don't see how we can do anything less than
> resolve the conflicts .. My cleanups first, then his code and condense
> and update his set. I'll gladly volunteer to do that.

Hmmm. I just don't quite see the severity of the conflict.

Nonetheless, code talks, so don't let me get in the way, but I really
think patching on top of the HRT queue is the best way forward. 

Even if they revert portions, it clearly points out why your changes
would be better, focusing the discussion, instead of just making a large
alternate patch queue.

-john

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