[lkml]   [2005]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH/RFC 10/10] example of simple continuous gettimeofday

Thomas, Ingo, I would really appreciate if you didn't pick up on some small
detail in my mail and draw final conclusions from it for the whole
discussion, before you even have seen the final result. I really thought I
made it clear, that this patch is more a proof-of-concept patch, which make
your comments rather pointless, especially since you leave the central parts
of the mail uncommented, you didn't even have a single question about it.
This either tells me you understood what I wrote, but it's beneath you to
comment on it or you didn't understand it and you just want me to shut up.
Either way I have a hard time not to take it personal.

On Thursday 22 December 2005 11:29, Thomas Gleixner wrote:

> Can we please concentrate on a clear and generic design model before
> discussing optimizations of 20 lines of code?

Fine with and that's exactly what the rest of the mail was about.

On Thursday 22 December 2005 10:01, Ingo Molnar wrote:

> Also, lets face it: with the union ktime_t type most of the '64-bit is
> slow on 32-bit' issues are much less of a problem. If some 32-bit arch
> wants to pull off its own timekeeping system, it can do so - but
> otherwise we want to move towards generic, unified (as far as it makes
> sense) and generally 64-bit-optimized subsystems. In 1995 i'd have
> agreed with Roman, but not in 2005.

ktime_t doesn't magically solve all problems, it just hides them better.
The main point of my mail is to provide a theoretical base of a good
gettimeofday implementation, which would allow a generic _and_ fast
implementation. Why do you insist on 64bit, if I can actually prove it's only
a waste of time?

bye, Roman

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-25 23:14    [W:0.048 / U:0.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site