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, 09 Oct 2006 00:35:08 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	akpm@...l.org, johnstul@...ibm.com, mingo@...e.hu,
	zippel@...ux-m68k.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: + clocksource-add-generic-sched_clock.patch added to -mm tree

On Sun, 2006-10-08 at 15:08 -0700, Daniel Walker wrote:
> > And why the heck does this require to move _clocksource_ related code
> > including sysfs hackery into timer.c ? Your improvement works with
> > extern code as well.
> 
> There are no clocksource internals added by me. There is a exposed
> clocksource API which is all that is used.

You move tons of code into timer.c, which does not belong there.
clocksource is a different thing than timekeeping. timekeeping makes use
of clocksources, and your extra layer of timekeeping_clocksource API
does not change that at all. What you call abstraction is just an
artificial extra layer, as it is intrinsically tied to the clocksource
core.

> The design of the original clocksource interface was specific for
> timekeeping. What I did was modified it to be used by more than just
> timekeeping.
> 
> If I add tons of externs there and cram all that into clocksource.c ,
> that would just be a mess. Then we're tending back to the original
> clocksource design when it's designed just for time keeping.

Tons of externs for the optimization of the clock source switch? Sorry,
I'm not following. 

The clock source switch happens once or twice during bootup and the
replacement of a call with an atomic check does not in any way
legitimate the move of code into timer.c. The number of cylces saved is
not impressing. Moving the clock source switch out of that path at all
would be progress and save real cylces. 
.
The maintainability of code has to weighed carefully against some
obscure cylce savings.

	tglx


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ