From: Andrew Lunn <andrew@lunn.ch>
To: Johannes Eigner <johannes.eigner@a-eberle.de>
Cc: netdev@vger.kernel.org, Michal Kubecek <mkubecek@suse.cz>,
Danielle Ratson <danieller@nvidia.com>,
Stephan Wurm <stephan.wurm@a-eberle.de>
Subject: Re: [PATCH ethtool 2/2] sff-common: Fix naming of JSON keys for thresholds
Date: Thu, 23 Oct 2025 15:14:15 +0200 [thread overview]
Message-ID: <af10599b-a698-4a60-a7d2-35a898b9a04a@lunn.ch> (raw)
In-Reply-To: <aPn9HkM-mjQHEo9v@PC-LX-JohEi>
> > As to ABI breakage, we have to consider, did this never work, so it
> > does not matter if we change it?
> >
> > 1) Does the first patch suggest it has always been impossible to get
> > this part of the module dumped in JSON format?
>
> Yes for SFP modules it was always impossible to get this part. But for
> QSFP and CMIS modules it should have worked before.
So we are potentially causing regressions, if anybody has an
application using these types of modules, and a forgiving JSON parser.
But the JSON is clearly broken, so we have to do something. The commit
message is important here, because if somebody does have a regression,
they find the commit which makes the change, we want to convince them
the consequences were considered, and they should just accept it,
rather than ask for a revert.
But we also have more flexibility for SFPs, if they never worked, we
can rename properties which are specific to them without issues. But
again, this should be explained in the commit message.
> For SFP modules it never worked, but for QSFP and CMIS modules it should
> have worked before. So I will try to minimize the effect for QSFP and
> CMIS modules.
Agreed
> For the biggest possible backward compatibility, I would suggest:
> * Keep the function sff_show_thresholds_json() as it is, so threshold
> values remain unchanged in the JSON output
> * Only rename the measured values if needed to avoid duplicated keys
> * Keep name "rx_power" for all module types
> * Keep name "laser_tx_bias_current" for QSFP and CMIS modules
> * Rename "laser_bias_current" to "laser_tx_bias_current" for SFP
> modules
> * Keep name "transmit_avg_optical_power" for QSFP and CMIS modules
> * Rename "laser_output_power" to "transmit_avg_optical_power" for SFP
> modules
> * Rename "module_temperature" to "module_temperature_measurement" for
> all modules
> * Rename "module_voltage" to "module_voltage_measurement" for all
> modules
>
> This results in only two keys renamed for QSFP and CMIS modules. As a
> side effect this also aligns the key names for the different module
> types.
This is good.
Thanks for the research you did into this, looking at difference JSON
libraries, etc.
Andrew
prev parent reply other threads:[~2025-10-23 13:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 14:00 [PATCH ethtool 0/2] fix module info JSON output Johannes Eigner
2025-10-21 14:00 ` [PATCH ethtool 1/2] sfpid: Fix JSON output of SFP diagnostics Johannes Eigner
2025-10-22 12:55 ` Danielle Ratson
2025-10-22 14:52 ` Johannes Eigner
2025-10-21 14:00 ` [PATCH ethtool 2/2] sff-common: Fix naming of JSON keys for thresholds Johannes Eigner
2025-10-22 13:32 ` Andrew Lunn
2025-10-22 14:59 ` Johannes Eigner
2025-10-22 15:34 ` Andrew Lunn
2025-10-23 10:02 ` Johannes Eigner
2025-10-23 13:14 ` Andrew Lunn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af10599b-a698-4a60-a7d2-35a898b9a04a@lunn.ch \
--to=andrew@lunn.ch \
--cc=danieller@nvidia.com \
--cc=johannes.eigner@a-eberle.de \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=stephan.wurm@a-eberle.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox