On Tue, Aug 22, 2023 at 02:36:31AM +0000, Mike Larkin wrote: > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > On Mon, Aug 21, 2023 at 10:10:58PM +0000, Mike Larkin wrote: > > > 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@). > > > > > > > > I am still seeking compile/boot-tests for the following: > > > > > > > > - alpha > > > > - hppa > > > > - m88k/luna88k > > > > > > if you are really interested in doing this [...] > > > > "really interested" is a bit strong. As always, my primary goal is > > not to break anything when I make a commit. > > > > The luna88k patch looks pretty straightfoward, but it's hard to be > > completely sure I didn't screw something up. > > > > > [...] you could run this in nono since you're just looking for > > > a compile/boot test. > > > > Apparently the license forbids redistribution. Super annoying. > > > > so? install it, boot a luna88k "vm", test your diff, then you have your > question answered. you aren't redistributing anything.
No, I mean that there is no binary for pkg_add, so I have to build it by hand. Unless I'm missing something?
