Re: 2.6.17-mm4

[john stultz]

On Sat, 2006-07-01 at 20:19 -0700, Andrew Morton wrote:
> On Sat, 01 Jul 2006 19:45:23 -0700
> john stultz <johnstul@xxxxxxxxxx> 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.

Actually, that should be ok as well, since we can safely change
clocksources while we're running.

Really, the only shared global state is the xtime value, and we handle
that safely as well. That reminds me, I need to freshen up my "remove
xtime references from i386" patch that will further clean this up.

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

Indeed.

thanks
-john



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/