> From: "Theo de Raadt" <deraadt@openbsd.org>
> Date: Tue, 22 Jul 2025 09:06:55 -0600
> 
> Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> 
> > > Date: Sun, 13 Jul 2025 16:22:03 +1000
> > > From: David Gwynne <david@gwynne.id.au>
> > > 
> > > a driver can depend on xcall and get this glue code compiled so it will
> > > work on arm64.
> > > 
> > > ok?
> > 
> > So what's the way forward here.  Theo objected to the extent of the
> > '#ifdef NXCALL > 0' and I think and then the discussion died?  I'm not
> > a fan of that either, but we also don't want that code in RAMDISK
> > kernels if we don't need it.  So perhaps just drop those here and make
> > the xcall stuff non-optional for MULTIPROCESSOR kernels?
> 
> 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.

Thinking about things a bit more, this "middle ground" I was proposing
doesn't actually work.  I think we either have to declare this
essential functionality and include it in all kernels, or we should
stick to using the xcall attribute.  The non-MULTIPROCESSOR
implementation is very small, so this isn't going to grow the RAMDISK
kernels by very much.

But yes, we want to use this, for MD code, soon, so maybe David should
just go ahead with what he has now until we have written the support
code for all the architectures (sparc64 is on my list).