> From: "Theo de Raadt" <deraadt@openbsd.org>
> Date: Sun, 13 Jul 2025 23:13:26 -0600
> 
> David Gwynne <david@gwynne.id.au> wrote:
> 
> > On Sun, Jul 13, 2025 at 07:17:00AM -0600, Theo de Raadt wrote:
> > > David Gwynne <david@gwynne.id.au> wrote:
> > > 
> > > > we just went through an effort to shrink kernel code to help the install media fit. it seems a bit ungrateful to use those bytes again for something that's generally only going to be used for performance monitoring.
> > > 
> > > Nope, that's not a good reason at all.  Prefer not to trade tons of cpp
> > > conditionals all over the place, for having more very different kernel
> > > execution behaviours.
> > > 
> > > OTOH, it will take some time to get this into all the architectures.  Once
> > > that's done, this should become a baseline feature.  Only then can MI code
> > > call it.   Providing it behind an #ifdef means that it should not be called
> > > from inside an #ifdef.
> > 
> > ok. how about hanging xcall off an archs cpu device until they're all
> > implemented, and not providing "xcall.h" so we can't have
> > #if NXCALL > 0?
> 
> or how about a simpler rule: noone can use it, until they're all implemented.
> that means you don't need the ifdef's.

We wan't to use this in MD-specific drivers.  With dlg's latest
proposals, those drivers can pull in the MI code bits by sepcifying
the xcall as a dependency in the <arch>/conf/files.<arch> file.

Using the code in a few MD-specific drivers will give us confidence
that we got the interface right before spending a lot of effort to
implement the MD bits.