Re: [PATCH 0/8] Introduce fwctl subystem

[Przemek Kitszel <przemyslaw.kitszel@intel.com>]

On 6/7/24 02:25, Jason Gunthorpe wrote:
> On Thu, Jun 06, 2024 at 10:24:46AM -0700, Dan Williams wrote:
>> Jason Gunthorpe wrote:
>> [..]
>>>> I am warming to your assertion that there is a wide array of
>>>> vendor-specific configuration and debug that are not an efficient use of
>>>> upstream's time to wrap in a shared Linux ABI. I want to explore fwctl
>>>> for CXL for that use case, I personally don't want to marshal a Linux
>>>> command to each vendor's slightly different backend CXL toggles.
>>>
>>> Personally I think this idea to marshal/unmarshal everything in the
>>> kernel is often misguided. If it is truely obvious and actually shared
>>> multi-vendor capability then by all means go and do it.
>>>
>>> But if you are spending weeks/months fighting about uAPI because all
>>> the vendors are so different, it isn't obvious what is "generic" then
>>> you've probably already lost. The very worst outcome is a per-device
>>> uAPI masquerading as an obfuscated "generic" uAPI that wasted ages of
>>> peoples time to argue out.
>>
>> Certainly once you have gotten to the "months of arguing" point it begs the
>> question "was there really any generic benefit to reap in the first
>> place?"
> 
> Indeed, but I've seen, and participated, in these things many times :)
> 
>> That said, *some* grappling, especially when muliple vendors hit the
>> list with the similar feature at the same time, has yielded
>> collaboration in the past.
> 
> Absolutely! But we have also frequently done that retroactively, like
> see three examples and then consolidate the common APIs. The challenge
> is uAPI. Since we can't change uAPI people like to rush to make it
> future proof without examples. Broadly I lean towards waiting until we
> have several examples to build a standard uAPI and let the examples
> evolve on their own.
> 
> If there is value in the commonality then people will change over.

what has changed over decades is that now Linux has much more users than
implementations of given tool

I would love to see a move of the uAPI barrier closer to the user,
we will be free to refactor kernel APIs, given "the system tool" will be
updated at the same time.
Obviously for a new uAPI that would (re)move the promise on the very
beginning.