On Tue, Jul 22, 2025 at 02:36:12PM -0600, Theo de Raadt wrote:
> Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> 
> > > From: "Theo de Raadt" <deraadt@openbsd.org>
> > > Date: Tue, 22 Jul 2025 10:19:51 -0600
> > > 
> > > Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > 
> > > > > That is my thought also.  If this is impossible to use without setting
> > > > > an option, then noone will use it.  If noone is using it, then why have
> > > > > the code at all?  I think we want it, because we know we need it (soon).
> > > > 
> > > > Actually xcall isn't an option; it is an attribute.  Drivers that need
> > > > the functionality ask for it by adding it as a dependency.  It is no
> > > > different than framebuffer drivers depending on rasops for example.
> > > 
> > > > So the question really is whether we intend to use this functionality
> > > > in generic code or not.  For now all the places where we intend to use
> > > > this are MD drivers.
> > > 
> > > That is surprising.
> > > 
> > > I was pretty sure the uses would either be in MD code only, or in
> > > MI /sys/kern /sys/net*, and /sys/uvm
> > > 
> > > I would be very surprised to see it used in MI drivers.
> > 
> > I said *MD* drivers, not MI drivers.
> 
> Sigh, we are talking past each other.
> 
> I believe it will be used in MI drivers and MI kernel.
> 
> David, do you really intend for this to be only used in MD drivers?

ive been kicking versions of this around for a few years, and the
only thing i've really truly hand on heart needed for is reading
special registers on individual CPUs, which is very MD.

the MI stuff we can do would be improving the implementation of things
like intr_barrier. there may be some benefit to quickly pushing work to
other parts of a system for numa or device topology reasons, but i don't
think we have enough other stuff ready for that.