On 6/5/24 7:59 AM, Jason Gunthorpe wrote: > On Tue, Jun 04, 2024 at 04:56:57PM -0700, Dan Williams wrote: >> Jakub Kicinski wrote: >> [..] >>> I don't begrudge anyone building proprietary options, but leave >>> upstream out of it. >> >> So I am of 2 minds here. In general, how is upstream benefited by >> requiring every vendor command to be wrapped by a Linux command? > > People actually can use upstream :) > > Amazingly there is inherit benefit to people being able to use the > software we produce. There is. There is a clear preference for open source kernels and drivers. Until a feature is standardized and/or commoditized, it does not make sense to create a uapi for every H/W vendor whim. All of them are attempting to solve real problems; some of them will stick. We know which features are valuable when customers use them, ask for them and other vendors copy them. Until then it is a 1-off by a vendor basically proposing a solution. Not all ideas are good ideas, and we do not need the burden of a uapi or the burden of out of tree drivers. > >> 3 years on from that recommendation it seems no vendor has even needed >> that level of distribution help. I.e. checking a few distro kernels >> (Fedora, openSUSE) shows no uptake for CONFIG_CXL_MEM_RAW_COMMANDS=y in >> their debug builds. I can only assume that locally compiled custom >> kernel binaries are filling the need. > > My strong advice would be to be careful about this. Android-ism where > nobody runs the upstream kernel is a real thing. For something > emerging like CXL there is a real risk that the hyperscale folks will > go off and do their own OOT stuff and in-tree CXL will be something > usuable but inferior. I've seen this happen enough times.. > > If people come and say we need X and the maintainer says no, they > don't just give up and stop doing X, the go and do X anyhow out of > tree. This has become especially true now that the center of business > activity in server-Linux is driven by the hyperscale crowd that don't > care much about upstream. Linux maintainer's don't actually have the > power to force the industry to do things, though people do keep > trying.. Maintainers can only lead, and productive leading is not done > with a NO. +1
