linux-kernel - Re: + clocksource-increase-initcall-priority.patch added to -mm tree

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1160326363.5686.48.camel@localhost.localdomain>
Date:	Sun, 08 Oct 2006 18:52:43 +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-increase-initcall-priority.patch added to -mm
	tree

On Sun, 2006-10-08 at 09:18 -0700, Daniel Walker wrote:
> > Early bootup Instrumentation is really not a good argument to make that
> > fragile time related stuff even more complex. There is no problem to
> > register reliable clocksources in early bootup, but do not make this
> > mandatory. Not every system is an ARM SoC, where you can and must rely
> > on the one source which is available usually right when the CPU comes
> > up.
> 
> It's not mandatory, it's just preferred.. As I said above, to avoid
> churn. I don't like the churn at boot up, and I tried to make sure there
> was none added in the patch set. 

What churn at bootup ? The clocksources _can_ be switched and it does
not matter, when this is done. We had the trouble with the early
registration a couple of month ago, and there is no reason to
reintroduce it. On systems which have exactly one clocksource, you can
register them early in bootup, but please do not touch the x86 setup for
no good reason.

	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/