On Mon, Jan 30, 2023 at 05:08:38PM +0100, Mark Kettenis wrote:
> > Date: Sat, 21 Jan 2023 17:02:48 -0600
> > From: Scott Cheloha <[email protected]>
> >
> > All the platforms have switched to clockintr.
> >
> > Let's start by isolating statclock() from hardclock(). stathz is now
> > always non-zero: statclock() must be called separately. Update
> > several of the the stathz users to reflect that the value is always
> > non-zero.
> >
> > This is a first step toward making hardclock and statclock into
> > schedulable entities.
> >
> > ok?
>
> If you are confident enough to start burning bridges, yes ok kettenis@
>
> Maybe you want to add
>
> KASSERT(stathz != 0);
> KASSERT(profhz != 0);
>
> at the start of initclocks() just to be sure?
>
> Either way is fine with me.
I thought about doing that, but those checks are done during
cpu_initclocks(), in clockintr_init():
60 void
61 clockintr_init(u_int flags)
62 {
63 KASSERT(CPU_IS_PRIMARY(curcpu()));
64 KASSERT(clockintr_flags == 0);
65 KASSERT(!ISSET(flags, ~CL_FLAG_MASK));
66
67 KASSERT(hz > 0 && hz <= 1000000000);
68 hardclock_period = 1000000000 / hz;
69
70 KASSERT(stathz >= 1 && stathz <= 1000000000);
Checking them again might make intent more explicit... still, I'm
leaning toward leaving them out.
