On 6/29/26, Maxime Chevallier wrote:

On 6/26/26 21:19, D H, Siddaraju 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.

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

Will wait for @Michal Kubecek's response about the manual page update
and as second possibility: options to update ethtool help string.

IMHO, yes the comment in ethtool.h enum definition is good
as it helps developers who use ethtool.h directly but from
ethtool app USER point-of-view, the manual page is the
first impression and ethtool --help is second. The effort here is
to help the user with a clarification, to avoid the clear confusion
with the wrong naming of 10000baseCR for all the major 4 reasons
listed in the first email of this thread. With that said, hope that
someone will also support the manual page update because
we think it is useful.

- Thank you,
Siddaraju D H