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