Messages in this thread | | | Subject | Re: + clocksource-increase-initcall-priority.patch added to -mm tree | From | Thomas Gleixner <> | Date | Sun, 08 Oct 2006 17:58:46 +0200 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |