Re: 2.6.17-mm4

Andrew Morton
2006-07-02T03:22:36Z

On Sat, 01 Jul 2006 19:45:23 -0700
john stultz <johnstul@us.ibm.com> wrote:

> > > Andrew: While clearly there is the deeper issue of why interrupts are
> > > enabled before they should be, I may still like to push the two-liner
> > > above, since its a bit safer should someone accidentally enable
> > > interrupts early again. Looking back in my patch history it was
> > > previously in the order above until I switched it (I suspect
> > > accidentally) in the C0 rework.
> > >
> > I looked at doing this and there appeared to be interdependencies between
> > these two functions. In that timekeeping_init()'s behaviour would be
> > different if time_init() hadn't run yet.
> >
> > So are you really really sure?
>
> timekeeping_init() is pretty straight forward:
>
> write_seqlock_irqsave(&xtime_lock, flags);
> clock = clocksource_get_next();
> clocksource_calculate_interval(clock, tick_nsec);
> clock->cycle_last = clocksource_read(clock);
> ntp_clear();
> write_sequnlock_irqrestore(&xtime_lock, flags);
>
> We initialize the clock value and call ntp_clear. The jiffies
> clocksource will be used to start - other clocksources will be selected
> as they become available.
>
> Just to be sure, which inter-dependencies where you're thinking of?

That time_init() might affect the behaviour of clocksource_get_next() by
changing global state.

But I guess the lack of a call to clocksource_done_booting() will prevent
that.