netdev - RE: [PATCH ethtool-next 08/14] cmis: Enable JSON output support in CMIS modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <DM6PR12MB45166DC5A99EC820E02FDF08D8F52@DM6PR12MB4516.namprd12.prod.outlook.com>
Date: Mon, 3 Feb 2025 09:58:27 +0000
From: Danielle Ratson <danieller@...dia.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Jakub Kicinski <kuba@...nel.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "mkubecek@...e.cz" <mkubecek@...e.cz>,
	"matt@...verse.com.au" <matt@...verse.com.au>, "daniel.zahka@...il.com"
	<daniel.zahka@...il.com>, Amit Cohen <amcohen@...dia.com>, NBU-mlxsw
	<NBU-mlxsw@...hange.nvidia.com>
Subject: RE: [PATCH ethtool-next 08/14] cmis: Enable JSON output support in
 CMIS modules

> From: Andrew Lunn <andrew@...n.ch>
> Sent: Sunday, 2 February 2025 21:41
> To: Danielle Ratson <danieller@...dia.com>
> Cc: Jakub Kicinski <kuba@...nel.org>; netdev@...r.kernel.org;
> mkubecek@...e.cz; matt@...verse.com.au; daniel.zahka@...il.com; Amit
> Cohen <amcohen@...dia.com>; NBU-mlxsw <NBU-
> mlxsw@...hange.nvidia.com>
> Subject: Re: [PATCH ethtool-next 08/14] cmis: Enable JSON output support in
> CMIS modules
> 
> >         "module_temperature": 37.3477,
> >         "module_voltage": 3.3406,
> 
> Device tree often puts the units in the property name.
> module_temperature_C, module_voltage_v,
> 
> >         "laser_bias_current": {
> >             "high_alarm_threshold": 13,
> >             "low_alarm_threshold": 3,
> >             "high_warning_threshold": 11,
> >             "low_warning_threshold": 5
> 
>              "high_alarm_threshold_mA": 13,
> 
> 
> >         },
> >         "laser_output_power": {
> >             "high_alarm_threshold": 3.1623,
> >             "low_alarm_threshold": 0.1,
> >             "high_warning_threshold": 1.9953,
> >             "low_warning_threshold": 0.1585
> >         },
> 
>              "high_alarm_threshold_W": 3.1623,
> 
> 
> >         "module_temperature": {
> >             "high_alarm_threshold": 75,
> >             "low_alarm_threshold": -5,
> >             "high_warning_threshold": 70,
> >             "low_warning_threshold": 0
> >         },
> 
>              "high_alarm_threshold_C": 75,
> 
> etc. This makes it more self contained.
> 
> 	Andrew

I suggested to have a separate field for units in the json output. It makes sense since it can be easily tracked by a machine and also it is aligned with the regular output.
Jakub offered to remove those fields from the output at all. And use a separate file for documenting those fields. In that case we are still aligned with regular output.
But in your suggestion, we should use a different naming convention in the JSON output, which not only complicates the code but is also confusing.

I think we should stick to the first 2 options.

Thanks.