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