Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

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

Hi,

On Sun, 16 Oct 2005, Thomas Gleixner wrote:

> > The spec is not really clear and Thomas refusal to explain his design 
> > decision is as also not really helpful. :-(
> 
> I did explain, why I did the rounding in the way it is implemented. If
> you define the fact that I have a different interpretation of SUS than
> you as refusal, then we can stop this thread right here.

I have no problem with you having a different opinion, I have a problem 
with your childish behaviour. :-(
You completely ignore the rest of my mail, trying to establish some base 
definitions, which would help to figure out the options we have based on 
the spec. You instead just insist on your interpretation without going 
into any detail.

> > He sets the timer resolution to (NSEC_PER_SEC/HZ) which matches no value 
> > above and this way he basically creates another virtual timer, which has 
> > only little to do with the real kernel timer tick.
> 
> As George explained already we return the resolution of the timer as the
> value which can be assumed to be the resolution of the event source,
> which drives the timer, because that seems to be the only interesting
> value for an application programmer. The theoretical resolution of a
> jiffie based timer system is NSEC_PER_SEC/HZ. 

You still don't explain, how you you get to this conclusion based on the 
spec. Instead you redefine it now to useful assupmtions for application
programmers who can't read the spec...
You still completely leave the question unanswered of the possibility of 
different resolutions. We can still discuss what resolution to return with 
clock_getres(), but first we have to establish with what kind of resoltion 
we're dealing with here.

> I really don't see any sense in returning changing resolution values
> every 5 minutes due to NTP adjustments. I imagine the happiness of
> application programmers which actually do calculations based on such a
> resolution value.

Why are they doing this kind of calculations based on this value?
We can discuss returning a reasonable value for these applications, but I 
don't see how these assumptions should control how the kernel works.

> And in the logical consequence you would have to save the original
> userspace timespec value including the time when the timer is set up and
> redo the rounding and calculation every time NTP changes the
> NSEC_PER_TICK value for _all_ timers which are related to
> CLOCK_MONOTONIC and CLOCK_REALTIME. 

The rounding is done based on your interpretation of the spec, which you 
refuse to discuss. AFAICT the spec leaves enough room to avoid this 
rounding completely.

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/