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, 01 Feb 2007 00:23:46 +0100
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Daniel Walker <dwalker@...sta.com>
Cc:	David Brownell <david-b@...bell.net>, linux-kernel@...r.kernel.org,
	john stultz <johnstul@...ibm.com>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 14/23] clocksource: increase initcall priority

Daniel,

On Wed, 2007-01-31 at 14:47 -0800, Daniel Walker wrote:
> > So don't assume any platform doesn't use clocksource initcalls.
> 
> What does your OMAP clocksource do now ? I thought one of the changes
> that you made was to have both 32k and mpu both registered ..

It is up to the clocksource driver, when the clocksource_register() call
is done. This may happen in early boot as well as after initializing
some other things first.

Johns clocksource code works with ARM which does the register call in
timer_init() as well as with some other hardware which gets initialized
late in the boot process.

clocksource_initcall is simply superfluid. 

Adjusting the initcalls of a particular device to the point where it
becomes available is a seperate topic. I'm not in the way of that and I
think John's patch draft to solve the sound issue is heading into
exactly this direction.

We do not need another initcall level, especially not one which just
aliases an existing one.

The only thing we really want to control explicitely is when we actually
switch away from jiffies_clocksource. But this does not need an
artificial initcall at all.

	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