Hi,
On Wed, 15 Feb 2006, john stultz wrote:
> I just wanted to make sure you know I'm not ignoring your suggestions.
> I do appreciate the time you have spent, and I have been continuing to
> work on implementing your idea. Unfortunately the code is not trivial
> and very much hurts the readability. I expect thats a sacrifice that
> will be necessary, but hopefully after some review cycles we'll be able
> to come to something we both like.
The code could be cleaned up a little, but the main difference is that my
code is much more compact, it lacks all the redundancy of your code, which
makes it harder to read. My hope was here instead of putting back the
code redundancy to add documentation instead, which would explain the
subtleties.
I actually think that the basic principle of my code is quite simple, the
problem is that it's a little buried inbetween how the incremental updates
are done in my prototype, so after a little cleaning and separating the
special cases, I think my code would be a lot more readable.
> I'm hoping to have a first pass patch I can mail this week.
I'm looking forward to it.
BTW What do you think how difficult it would be to rebase your patches on
my NTP4 patches? In the end the simplification of my patches should also
make your patches simpler, as it precalculates as much as possible and
reduces the work done in the fast paths. It would avoid a lot of extra
work, which you currently do.
The main problem that I see is that you need to drop the ppm calculations,
the new code provides a scaled nsec value per tick (tick_nsec + time_adj)
and you basically only need "(update - 10^9/HZ) / cycles" to calculate the
new multiplier adjustment.
You also need to drop your ntp rework, the changes to the generic code
should be quite simple now, basically just exporting second_overflow()
and creating an alternative do_timer() entry point which doesn't call
update_wall_time().
Besides some small cleanups I think my code is ready for some serious
testing, but it conflicts with your NTP changes.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
