Re: [PATCH] xen: Put wait.c behind CONFIG_WAIT

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Feb 12, 2026 at 02:14:58PM -0500, Jason Andryuk wrote:
> On 2026-02-12 02:38, Jan Beulich wrote:
> > On 11.02.2026 18:30, Andrew Cooper wrote:
> > > On 11/02/2026 5:01 pm, Jason Andryuk wrote:
> > > > wait.c is only used by vm_event.c.  Make CONFIG_VM_EVENT select
> > > > CONFIG_WAIT, and use CONFIG_WAIT to control building it.
> > > > 
> > > > Provide stubs of functions called from common code.  entry.S needs an
> > > > ifdef to hide the symbol from the assembly.
> > > > 
> > > > Also conditionalize .waitqueue_vcpu in struct vcpu to save space.
> > > > 
> > > > Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> > > 
> > > I'd really rather see the API/ABI changes required to purge wait.c
> > > entirely, but I guess this will do in the short term.
> > > 
> > > Two things want further thought.
> > > 
> > > First, because ARM uses per-vCPU stacks not per-pCPU stacks, it doesn't
> > > need this infrastructure in the first place, but it looks like it's
> > > still compiled in and half wired up.  I suppose you don't notice because
> > > you compile out VM_EVENT on ARM too?
> > 
> > But if we want it compiled out altogether on Arm, ...
> > 
> > > Second CONFIG_WAIT isn't great name because there are many things it
> > > could be.  I'd be tempted to just reuse CONFIG_VM_EVENT and go without
> > > CONFIG_WAIT.  I do not want to see any new users of wait.c, and it will
> > > disappear at some point.
> > 
> > ... don't we need a separate kconfig control, for it to be selected only
> > on x86 (or for it to be dependent on x86, and then imply-ed)? Imo
> > CONFIG_WAITQUEUE would be okay, as long as it won't have a prompt. We'd
> > then simply want to prevent further select-s / imply-s to appear.
> 
> ARM VM_EVENT=y won't link without wait.o.  Undefined references to:
> wake_up_nr
> prepare_to_wait
> finish_wait
> destroy_waitqueue_head
> init_waitqueue_head
> 
> So I think that points to re-using my original patch, but with either
> CONFIG_WAITQUEUE or CONFIG_VM_EVENT.  Since CONFIG_VM_EVENT is the only
> user, and we don't want further uses, I would use that.  But I am open to
> either.

I think hiding behind CONFIG_VM_EVENT is better, we want to avoid new
instances of waitqueue (at least in it's current state), so not sure
it makes a lot of sense to add it under a different Kconfig option if
our intention is for waitqueue to only be used with VM events.

Thanks, Roger.