In days of yore (Sat, 27 Apr 2024), Dan Williams thus quoth: > Greg KH wrote: > [..] > > So while innovating at the hardware level is fine, follow the ways that > > everyone has done this for other specification types (USB, PCI, etc.) > > and just allow vendor drivers to provide the information. Don't do this > > in crazy userspace drivers which will circumvent the whole reason we > > have standard kernel/user apis in the first place for these types of > > things. > > Right, standard kernel/user apis is the requirement. > > The suggestion of opaque vendor passthrough tunnels, and every vendor > ships their custom tool to do what should be common flows, is where this > discussion went off the rails. One aspect of this is Fabric Management (thinking CXL3 here). It is not desirable that every vendor of CXL hardware require their own (proprietary) fabric management software. From a user perspective, that is absolutely horrible. Users can, and will, mix and match CXL hardware according to their needs (or wallet), and them having to run multiple fabric management solutions (which in worst case are conflicting with each other) to manage things is .. suboptimal. By all means - innovate - but do it in such a way that interoperability and manageability is the priority. Special sauce vendor lock-in is a surefire way to kill CXL where it stands - don't do it. -- Kind regards, /S
