On Mon, Jan 25, 2021 at 6:01 PM Jakub Kicinski <kuba@kernel.org> wrote:

> > Since changing the hierarchy does constitute an ABI change, it must
> > be explicitly requested via RTEXT_FILTER_VF_SEPARATE_STATS. Otherwise,
> > the old location is maintained for compatibility.
>
> We don't want any additions to the VF ABI via GETLINK. IMO the clear
> truncation is fine, hiding stats is pushing it, new attr is a no go.

How does one fix an API bug if one is not allowed to change it in any way?

Perhaps that's a rhetorical question, but I had hoped we could be more
pragmatic. I'm not particularly proud of this proposed patch on its
standalone technical merits. There are obviously far superior
solutions if we are permitted to add to the GETLINK VF API in a
meaningful way. That said, it does present a compromise that cannot be
construed as adding capabilities to a deprecated API. Instead of
adding new operations that don't suffer the same ills, it merely moves
existing structures around without changing any of the semantics of
the prevailing request.

By drawing such a hard line in the sand, you are declaring that this
bug has no possible resolution by decree. With my vendor hat on, it's
probably no skin off my teeth - all my competitors suffer the same
Linux usability issue. As a long time Linux user and somebody who
cares about the customer experience, it just makes me sad. :( There's
a difference between encouraging people to move towards a newer API,
by insisting that the development of new functionality happens there,
and actively making sure the old API sucks to use.

Regards,
Edwin Peer