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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.02.2026 20:14, 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

Hmm, okay, assuming that then also actually works, ...

> 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.

... please do.

Jan