Re: [RFC - 0/13] NTP cleanup work (v. B5)

[Roman Zippel]

Hi,

On Mon, 15 Aug 2005, john stultz wrote:

> > I think most of this is premature cleanup. As it also changes the logic in 
> > small ways, I'm not even sure it qualifies as a cleanup.
> 
> Please, Roman, I'm spending quite a bit of time breaking this up into
> small chunks specifically to help this discussion. Rather then just
> stating that the logic is changed in small ways, could you please be
> specific and point to where that logic has changed and we can fix or
> discuss it.

Well, part of the problem is that you didn't really explain, why your 
logical are better in any way. You broke them out of your big patch and 
they lose their context.
It's probably better to first to understand and agree on the functional 
changes, moving code around can still be done afterwards.

> > For the rest I can't agree on to move everything that aggressively into 
> > the ntp namespace. The kernel clock is controlled via NTP, but how it 
> > actually works has little to do with "network time". 
> 
> Eh? The adjtimex() interface causes a small adjustment to be added or
> removed from the system time each tick. Why should this code not be put
> behind a clear interface?

I don't mind the clear interface...

> > Some of the 
> > parameters are even private clock variables (e.g. time adjustment, phase), 
> > which don't belong in any common code. (I'll expand on that in the next 
> > mail.)
> 
> Again, I'm not understanding your objection. Its exactly because the
> time_adjust and phase values are NTP specific variables that I'm trying
> to move them from the timer.c code into ntp.c

The point is you're starting at the wrong point, first we need a clean 
clock interface, only then should we change the ntp code to it.
(More again in the next mail.)

bye, Roman
-
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/