Early in my Linux career there was palpable concern around Linux being locked out of future computing platforms by hardware vendors who did not provide open drivers, or even documentation for their hardware. For the hardware vendors that did participate upstream, maintainers used code acceptance to influence them towards common Linux commands and cross-vendor cooperation. The internalized lesson from those days was: "Be wary of vendors pushing 'do anything you want and get away with it' passthrough tunnels. Demand open documentation of all interfaces." Present day realities and discussions merit revisiting that lesson: 1/ The truth of the matter is that until the Kernel Lockdown facility arrived, device vendors *had* an unfettered passthrough tunnel via userspace driver mechanisms like /dev/mem and pci-sysfs. The presence of those facilities did not appear to injure the ascension of Linux. 2/ Device passthrough, kernel passing opaque payloads, is already taken for granted in many subsystems. USB and HID have "raw" interfaces, EFI variables provide platform-specific configuration, and the oft-cited examples of SCSI and NVME that provide facilities to marshal any command payload whether mainline maintainers think the functionality is a good idea or not. In the case of NVME, the specification continues to evolve despite this Linux bypass. 3/ The practice of requiring Linux commands to wrap all device commands does not appear to have accelerated upstream participation in the CXL subsystem. I.e. CXL, in contrast to NVME, relegates passthrough to a build-time debug option. Some vendors are even shipping vendor specific firmware update facilities even though mainline has support for the CXL standard firmware update mechanism. With the impending arrival of CXL switch devices wanting to share mailbox handling code with the CXL core, the prohibition of device-specific commands is going to generate significant upstream work to wrap all that in Linux commands with little perceivable long term benefit to the subsystem. CXL and RDMA are also foreshadowing conflicts across subsystems. It is not difficult to imagine a future CXL or RDMA device that supports mem, block, net, and drm/accel functionality. Which subsystem's device-command policy applies to such a thing? 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. 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. 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. 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. [1]: http://lore.kernel.org/0-v2-940e479ceba9+3821-fwctl_jgg@xxxxxxxxxx
