> Date: Tue, 31 Jan 2023 04:50:59 -0600
> From: Scott Cheloha <scottchel...@gmail.com>
>
> 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 <scottchel...@gmail.com>
> > >
> > > 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.
Ah, sure, yes, that's fine.
