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.
