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 07:53:21 -0800
From:	Daniel Walker <dwalker@...sta.com>
To:	tglx@...utronix.de
Cc:	Ingo Molnar <mingo@...e.hu>, Andrew Morton <akpm@...l.org>,
	LKML <linux-kernel@...r.kernel.org>,
	John Stultz <johnstul@...ibm.com>,
	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:13 +0100, Thomas Gleixner wrote:
> On Wed, 2007-01-24 at 02:23 -0800, Daniel Walker wrote:
> > > the 10th major iteration to his codebase. If you have cleanups to his 
> > > code then please work with Thomas to get your changes into his tree.
> > 
> > My code is for clocksouces/timekeeping which has been unrelated to HRT
> > up until recently. In my original email I suggested that the two tree's
> > be merged ,or placed on top of each other, which I still think is a good
> > idea.
> 
> This would require, that your patches are solving a real problem. The
> last time I looked at them was before they were dropped from -mm. I
> disagreed with your intent of sched clock changes back then and I still
> do.

My patch set was considered for -mm , but was never included. Andrew
only stop considering my set because I obsoleted them.

My patches are almost all cleaning up the interface. Adding a generic
sched_clock is just a by product of the clean up. Your changes just add
more mess/confusion that would need to be handled later.

> OTOH, I needed a clean solution for the TSC verification to get rid of
> the hardwired hackery in tsc.c. The flag change is just used for this
> and can be extended for other purposes.

I don't see a justification for the level of changes your making. Your
making substantial changes to a small clocksource interface so you can
check the output of one clock against another clock. That process is
designed specifically for the TSC and only used by the TSC .. It's not
likely that process would be needed on any other architectures.

So your really just adding a bunch of generic overhead to the detriment
of the interface.

Daniel

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