Shouldn't this be in userspace?

The subsystem appears to introduce a sysfs interface, which revolves around a character device that can be read from/written to via user/kernel space. It implements a number of operations that allow initializing the interface, attaching it to subsystems, and clearing the dataset, as well as setting a couple "modes" for the device that inform policy on how the "recommendations" are intended to be used. It looks like there is a notification mechanism for passing events from kernel space as well, for what looks like triggering backpropagation.

1) The patch's documentation is missing/poor. Many of the constants are undocumented, and there are no additons to Documentation/.

2) I don't see any kernel selftests, kunit or otherwise, to test correctness of the series.

3) While I see a "test driver" interface being added to lib/ the code lacks any example implementation of an existing kernel subsystem pushing data to be used by this series. So while you might be able to create and instatiate an interface, I don't see any actual implementation from the individual subsystems to actually provide data for the model. So this series is missing that critical piece.

4) The author needs to specifically address why this belongs in kernel space and can't be implemented through existing means.

Overall, I think this series is unsuitable in the current state, and raises architectural questions that need anwering before any serious consideration. I think that it's difficult to justify an ML specific interface for driving kernel policy when well-tested, existing mechanisms exist for reading kernel logs and events and pushing policy (audit subsystem / ebpf programs and hooks).

Whether this is AI generated or not, I'm 50/50. The code looks *vaguely* correct to me, but the wording is a little circular and unclear, so it's entirely possible. I'm not super optimistic at this point about it.