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

[Thomas Gleixner <tglx@linutronix.de>]

On Sun, 2006-10-08 at 08:45 -0700, Daniel Walker wrote:
> > I'd like to know, why we need to move that and you did not explain _why_
> > it is likely that it is used during bootup.
> 
> If the clocksources are registered at the same time as the clocksource
> users then you end up with users frequently switching clocks during boot
> up. The original clocksource code solved this by not allowing a real
> clocksource lookup until after the system fully booted.

No, that was not the reason. It does not hurt anything, when the
clocksource changes during bootup. You simply replace one read out
device by another one.

The reason was that we wanted to select clocksources as late as
possible, as we wanted to have late init clocksources ready and TSC
problems outruled.

> However, if you put all the clocksources into postcore initcall, with
> that being known in advance, and all the users are in lower priority
> initcalls then you don't need extra code to prevent churn during bootup.
> 
> The reason that I think this will get used during boot up is because
> some of the target users will be instrumentation, and (my prediction
> anyway) is that some will need to use the interface early. Still even
> postcore may not be early enough.

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.

Early bootup instrumentation can very well go with none or coarse
grained time information, if there is a need to have early boot
intstrumentation at all.

	tglx