Re: [PATCH 0/8] Introduce fwctl subystem

David Ahern
2024-06-06T02:35:51Z

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