From: Mark Kettenis Subject: Re: cpu_xcall glue for arm64 To: "Theo de Raadt" Cc: david@gwynne.id.au, tech@openbsd.org Date: Tue, 22 Jul 2025 18:09:26 +0200 > From: "Theo de Raadt" > Date: Tue, 22 Jul 2025 09:06:55 -0600 > > Mark Kettenis wrote: > > > > Date: Sun, 13 Jul 2025 16:22:03 +1000 > > > From: David Gwynne > > > > > > 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).