Re: [PATCH] Clean up of hrtimer code.

[Thomas Gleixner]

George,

On Thu, 2006-01-19 at 12:53 -0800, George Anzinger wrote:
> > The assumption that the CLOCK_REALTIME/MONOTONIC relationship is valid
> > for all additional clocks is not correct.
> 
> Well, it is until it isn't.  There really does need to be a paring of some 
> sort to sort out the ABS flag.

How is this applicable to some additional non posix clocks ? It applies
to CLOCK_MONOTONIC and CLOCK_REALTIME, but nothing speaks against
implementing CLOCK_WHATEVER with a totally different behaviour vs. the
ABS_TIME flag. Am I missing something ?

> >> 
> >> static inline int common_timer_create(struct k_itimer *new_timer)
> >> {
> >>-	hrtimer_init(&new_timer->it.real.timer, new_timer->it_clock);
> > 
> > 
> > I kept that init as a dummy one. Thats simpler than adding all the 
> > if(!base) stuff into the hrtimer code. Not having those checks gives a
> > nice oops, when somebody tries to access a non initialized hrtimer !
> 
> An additional problem that you may want to address it that the SIGEV_NONE 
> timers never get their time set (that being done by being put in the timer 
> queue) and so the return value on a timer_gettime() is wrong.  I have updated 
> the absolute timer test on sourceforge (in the CVS) to test for this, and, of 
> course it fails.  I, in one version, added a NO_QUEUE flag to the mode to 
> tell the enqueue_timer code to return just prior to actually doing the 
> enqueue to handle this.  The other possibility is to fill the expire time in 
> in posix-timers.c, but that means it has to do stuff that is already coded in 
> enqueue_timer.  Your choice, but currently what happens is wrong.

Thanks for pointing this out. I fix this before pushing stuff.

	tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/