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:	Thu, 25 Jan 2007 07:37:39 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	john stultz <johnstul@...ibm.com>,
	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

* Daniel Walker <dwalker@...sta.com> 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. [...]

if it were the same area of code, and if all your cleanups were fine, 
i'd agree. But even assuming that all your cleanups are fine, this is 
90% /not/ the same area of code. Thomas's changes refactor the 
clockevents infrastructure, while passingly touching clocksources too, 
on an as-needed basis. Your changes touch the clocksource area of code. 
In that sense Thomas' changes are more important and you should be able 
to refactor your queue ontop of Thomas' (trivial) change to the 
clocksources code.

You are complaining that we didnt pick up your high-flux cleanups, but 
we pointed out our reasons. In fact we couldnt really even consider your 
queue because the last version of yours when we did ours was 2 months 
old and yours included the showstopper sched_clock() changes. Your queue 
had all the signs of abandonment, so your injection into this submission 
of the -hrt queue to suggest that your queue is suddenly a 'must have' 
is quite puzzling to me.

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