On Fri, Jun 13, 2025 at 04:58:27PM +0200, Pratyush Yadav wrote: > On Sat, Jun 07 2025, Pasha Tatashin wrote: > [...] > >> > >> This weirdness happens because luo_prepare() and luo_cancel() control > >> the KHO state machine, but then also get controlled by it via the > >> notifier callbacks. So the relationship between then is not clear. > >> __luo_prepare() at least needs access to struct kho_serialization, so it > >> needs to come from the callback. So I don't have a clear way to clean > >> this all up off the top of my head. > > > > On production machine, without KHO_DEBUGFS, only LUO can control KHO > > state, but if debugfs is enabled, KHO can be finalized manually, and > > in this case LUO transitions to prepared state. In both cases, the > > path is identical. The KHO debugfs path is only for > > developers/debugging purposes. > > What I meant is that even without KHO_DEBUGFS, LUO drives KHO, but then > KHO calls into LUO from the notifier, which makes the control flow > somewhat convoluted. If LUO is supposed to be the only thing that > interacts directly with KHO, maybe we should get rid of the notifier and > only let LUO drive things. Yes, we should. I think we should consider the KHO notifiers and self orchestration as obsoleted by LUO. That's why it was in debugfs because we were not ready to commit to it. Jason
