Re: Straw proposal: MI kthread vector/fp unit API

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sat, 20 Jun 2020 18:52:03 -0700
> From: Erik Fair <fair%netbsd.org@localhost>
> 
> Back in the day, these additional (potentially optional) computation
> units (e.g., FPU, GPU, vector engine(s)) were generically referred
> to as "co-processors" as a class.

Only units that are normally accessible through ordinary CPU
instructions by user processes but prohibited in the kernel, with
registers that must be preserved across context switches according to
the architecture's ABI, are in scope in this proposal.

Thus, for example, the Intel x87 floating-point unit, the Intel SSE
FP/vector unit, the ARM VFP or NEON units, and the PowerPC FPU and
Altivec unit are all in scope; GPUs, FPGAs, crypto decelerator devices
on the PCI bus, and Cell SPEs are nowhere near the scope.

I considered `fpu', `simd', `vector', and `vfp'.  `vfp' is a specific
family of floating-point vector units in the ARM world, so that would
be confusing in an ARM context where it would also apply to NEON or
the AArch64 SIMD/FP unit.  Neither `simd' nor `vector' applies to the
x87, and `fpu' doesn't apply to the MIPS DSP, but `fpu' struck me as
more recognizable and distinct -- for instance, we also have interrupt
`vectors' and operations `vectors' in the kernel which are unrelated.

I'm open to other naming suggestions but I'm deliberately keeping the
scope narrow and grounded by specific needs.