> How hard is that "jump through hoops" thing anyway? I'd conservatively estimate 500 lines of duplicated code from the CXL subsystem just to handle the setup and discovery of the mailbox, plus all the checks needed to establish the device is in a state to reply. Also locking or module load ordering constraints because we need to ensure mutual exclusion on that mailbox between this module and the CXL core. So it would approximately triple the size of this driver to check for CXL scrub support. Not to mention hotplug - which could possibly be solved with appropriate udev rules to try loading this again whenever a CXL memory device gets plugged in. Alternative would be to make this ras class driver dependent on the CXL driver stack running first. Thus if you wanted RAS2 ACPI table support, you'd need to load a whole bunch of CXL stuff. Add another similar driver in future and we get another few 100 lines of code or another dependency. To me those numbers make it unsustainable. > > You mean it should load so that when booting an allmodconfig kernel there are not enough modules which are loading so lemme load one more. And then I need to go and rmmod them all before I need to do localmodconfig and build a tailored kernel for the machine. > > Or is there some other reason to load silly modules, use up resources for no good reason whatsoever and bloat the machine? As Dan, Shiju and I observed (and Shiju tested to be sure we weren't getting it wrong), normal setups including your allmodconfig build would not even load the driver. What are we missing? Jonathan
