On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > This is the next patch in the clock interrupt reorganization series. > > > > Before we continue breaking up the hardclock(9) we need to detour into > > the MD code. > > > > This patch divides the "initialization" parts of cpu_initclocks() from > > the "start the clock interrupt" parts. Seprating the two parts leaves > > initclocks() an opportunity to prepare the primary CPU for clock > > interrupt dispatch in a machine-independent manner before actually > > pulling the trigger. It's nearly impossible to do any MI setup during > > initclocks() because cpu_initclocks() does everything in one go: both > > initialization and kickoff are done when cpu_initclocks() returns. > > > > Many platforms have a "cpu_startclock()" function, so this patch takes > > that de facto standard and makes it a rule: cpu_startclock() is now > > required. It is prototyped in sys/systm.h and every platform must > > implement it. > > > > The revised initclocks() sequence is then: > > > > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures > > hz, stathz, and profhz are initialized. All the machine > > independent setup in step (2) (currently) depends upon > > these machine-dependent values. > > > > 2. Compute intervals using hz, stathz, and profhz. > > > > In a later step I will move the full contents of clockintr_init() > > up into initclocks() and get rid of clockintr_init() entirely. > > > > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the > > clock interrupt dispatch cycle on the primary CPU. > > > > I have compiled/booted this patch on amd64 (lapic path), arm64, i386 > > (lapic path), macppc, octeon, and sparc64 (sun4v). > > > > I am looking for compile/boot tests on alpha, armv7, hppa, landisk, > > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one > > here. Everything else is relatively straightforward, though I may > > have missed a few stray variables here or there. > > > > Test results? Ok? > > Here is an updated patch that removes several MD prototypes for > cpu_startclock() that I missed the first time through. > > I went back and tested these again: > > - amd64 (lapic) > - arm64 > - i386 (lapic) > - powerpc/macppc > - mips64/octeon (loongson should be fine) > - sparc64 (sys_tick; tick/stick should be fine) > > arm/armv7 and riscv64 were tested under the previous version, but I > would appreciate a second compile-test to make sure the header changes > in the updated patch did not break the build (CC phessler@, jsg@).
Still builds on riscv64 and armv7.