This would imply there is now some job for glibc. However it's still
unclear for me how the glibc would know about wich value it should
return while this question would be so easy to answer for the kernel!
Also AFAIK, right now, only the NPTL supports the new syscalls for the
timers (and none supports the clocks syscalls). Does it mean a special
__sysconf() is necessary in the NPTL? Well, probably that's why you
suggested -1 as a return value I guess :-)
>
> Anyway, in this specific case the implementation should be protected
> against the ever so improbable overflow of the counter, yes. If you
> want a fixed value, fine. If you want to use ULONG_MAX (or whatever),
> good too. Whether we advertise this limit is another thing.
> Advertising it in the macro means it never can be changed.
>
You are right also here, of course with this point of view it's
better not putting any constant.
So the patch could become something like that: ?
diff -ur linux-2.5.67-ia64-hrtcore/include/linux/posix-timers.h linux-2.5.67-ia64-hrtimers/include/linux/posix-timers.h
--- linux-2.5.67-ia64-hrtcore/include/linux/posix-timers.h 2003-04-22 11:10:44.000000000 +0200
+++ linux-2.5.67-ia64-hrtimers/include/linux/posix-timers.h 2003-05-06 16:07:56.000000000 +0200
@@ -25,6 +59,7 @@
#define posix_bump_timer(timr) do { \
(timr)->it_timer.expires += (timr)->it_incr; \
- (timr)->it_overrun++; \
+ if ((timr)->it_overrun < INT_MAX)\
+ (timr)->it_overrun++; \
}while (0)
#endif
Eric
-
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/