On Sat, Mar 18, 2006 at 05:39:03PM +0900, YAMAMOTO Takashi wrote:
[]
> > To generate a diff of this commit:
> > cvs rdiff -r1.9 -r1.10 src/sys/arch/xen/i386/identcpu.c
> > cvs rdiff -r1.17 -r1.18 src/sys/arch/xen/xen/clock.c
> 
> KDASSERTs you added don't seem always true.

Looking at them again, they are:

1) That the cycle counter hasn't gone backwards (or stopped).
2) That >1s doesn't seem to have passed, in xen_microtime, since
   the last clock interrupt.
3) That hardclock(9) hasn't set the time back nor advanced it by >1s.

Part of my intent here was to avoid the situation that started this,
where unreasonable values got into cc_microtime, because the underlying
"hardware" wasn't behaving as assumed, and then passed on into userland.

> i don't think assertions are appropriate for this kind of things.

Looking at this again, I think I agree.  But I'm not sure if they should
become printf's conditionalized on DEBUG, or removed/commented out, or
something else.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))