Re: [PATCH 1/5] generic clocksource updates

[Thomas Gleixner <tglx@linutronix.de>]

Roman,

On Fri, 2006-04-07 at 22:43 +0200, Roman Zippel wrote:
> > > Currently this field isn't needed and as soon we have a need for it, we 
> > > can add proper capability information.
> > 
> > Is there a reason, why requirements which are known from existing
> > experience must be discarded to be reintroduced later ?
> 
> Then please explain these requirements.

I explained them very clear in my original post:

http://marc.theaimsgroup.com/?l=linux-kernel&m=114431804702870&w=2

> This field shouldn't have been added in first place, I guess I managed to 
> confuse John when I talked about handling of continuous vs. tick based 
> clocks.

I appreciate your responsibility, but the is_continous field was
introduced on my request because I did not want to rely on (rating > X)
to decide whether I can safely switch to high resolution timer mode or
not.

I really do not understand, why you claim to be the ultimate authority
to decide whats right and wrong in this area. Can you please shed some
light on my agnostic mind with some _real_ explanation why you can claim
to have the authority to decide whats needed and whats not needed ?

"Currently this field isn't needed and as soon we have a need ....".
----------------------------------------------^^^^

I guess http://en.wikipedia.org/wiki/Pluralis_Majestatis is the right
place for me until you start to explain.

> Currently no user should even care about this, it's an 
> implementation detail of the clock.

Right. Even if no user cares about this right now, nevertheless
forseeing the requirements of the near future is the finer art of
engineering. Especially if there is existing experience, which shows
that it is necessary.

	tglx