Source-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch/xen
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)))))
Home |
Main Index |
Thread Index |
Old Index