On Mon, Jul 08, 2024 at 03:26:43PM -0700, Dan Williams wrote: > Enter the fwctl proposal [1]. From the CXL subsystem perspective it > looks like a long-term solution to the problem of managing expectations > between hardware vendors and mainline subsystems. It disclaims support > for the fast-path (data-plane) and is targeted at the long tail of > slow-path (config/debug plane) device-specific operations that are often > uninteresting to mainline. That's not true at all, device-specific operations are very interesting to mainline, and I would argue that the "slow-path" is the most important thing for the kernel to manage as that is where the security and unification layers can be properly enforced. Vendors that think the control plane should just be allowed to be accessed by userspace "blindly" are not saying outloud that they just want to circumvent the security layer entirely like they previously were doing by directly accessing /dev/mem which is one of the strongest reasons to keep enforcing this through the kernel as Christoph points out. It's the cumulation of multiple vendors of semi-alike config paths that allow us to standardize them to provide the most important thing of all, a unified view to userspace where a user does not care about what type of hardware is running, which is really the goal of Linux as well, but directly goes against what a vendor wants to have happen. > It sets expectations that the device must > advertise the effect of all commands so that the kernel can deploy > reasonable Kernel Lockdown policy, or otherwise require CAP_SYS_RAWIO > for commands that may affect user-data. Yes, this is a good start, but it might still be too "vendor-specific" at this point in time. > It sets common expectations for > device designers, distribution maintainers, and kernel developers. It is > complimentary to the Linux-command path for operations that need deeper > kernel coordination. Yes, it's a good start, BUT by circumventing the network control plane, the network driver maintainers rightfully are worried about this as their review comments seem to be ignored here. The rest of us maintainers can't ignore that objection, sorry. > The upstream discussion has yielded the full spectrum of positions on > device specific functionality, and it is a topic that needs cross-kernel > consensus as hardware increasingly spans cross-subsystem concerns. > Please consider it for a Maintainers Summit discussion. SHould be a fun discussion, thanks for proposing this. greg k-h
