On Mon, Jun 29, 2026 at 11:30:43AM GMT, Maxime Chevallier wrote:

quoted

What about
"option-(b): create a new enum ETHTOOL_LINK_MODE_10G_SFI_DA_Full_BIT"?
  Idea is just to create a new enum, with same enum value of 10000baseCR.
  This will NOT consume a bit position in "ethtool_link_mode_bit_indices".
  It just helps those tech-savvy people, who does not accept 10000baseCR
  and prefer 10000sfiDA for being explicit.

The thing is that even with a new enum value, that won't bring much to
the table. It would likely be better to have a comment near the
10000baseCR definition explaining the SFF equivalency.

quoted

At worst case, hope we agree for
"option-(c): ethtool.8 man page help strings to indicate 10G_SFI_DA"
  Something like
    "10000baseCR (10G_SFI_DA    SFF-8431 SFP+ DA)
  under "advertise" mask values.

In that case, let's add Michal in the loop as the ethtool maintainer. Even
then it's not straightforward as some tooling relies on the JSON output
from ethtool, so _if_ we change the output for that mode, it should only
be in the non-json output.

The biggest problem I see here is that even if ethtool has its own link
mode tables, those are only for backward compatibility and as long as
reasonably new ethtool and kernel are in use, ethtool gets the link mode
names from kernel. There are multiple aspects:

1. The UAPI constants. These are part of kernel uAPI and ethtool just
gets a sanitized copy of kernel file. In other words, if we want any
change here (even adding a comment), it has to be done on kernel side
and ethtool gets the change on next uapi sync. Adding an alias here
would be quite simple.

2. Link mode names as shown in "ethtool <dev>" output. These are
normally retrieved from kernel via the ETH_SS_LINK_MODES string set.
In other words, if any change were desired, it would have to happen on
kernel side as well. And unless we add a specific exception to the code,
the same name is shown in both plain text and json output. (Personally
I don't think it would be a good idea to show different name in each.)

3. Link mode names that can be used in "ethtool -s" command line. These
are handled exactly the same way as names used for output. Here I could
imagine an alias implemented on ethtool side but it would have to be
hard coded in ethtool and it would only work in (new versions of)
ethtool. In general, names shown by "ethtool <dev>" should match those
expected on "ethtool -s" command line, any mismatch would be very
confusing and impractical.

4. Adding a text to ethtool(8) manual page is possible. While most of
the link mode table in the man page is (unsurprisingly) generated, it is
then reordered manually and adding a note would definitely be possible.
One just needs to be careful about the table formatting. (Yes, I'm aware
that this table has been getting out of hand for some time and I'm
thinking about ways to make it more readable and useful. Suggestions are
welcome.)

My personal opinion would be that adding a comment in the enum definition
near 10000baseCR is enough :/

That would certainly be the easiest solution but as I said above, it
would be a kernel code change, ethtool would just inherit the updated
header file.

Michal