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 <[email protected]>
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.
Regards,
Jason
