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 [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]
