Re: [PATCH/RFC 10/10] example of simple continuous gettimeofday

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/