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:
 <DM6PR12MB4516FF124D760E1D3A826161D8EE2@DM6PR12MB4516.namprd12.prod.outlook.com>
Date: Wed, 29 Jan 2025 07:06:09 +0000
From: Danielle Ratson <danieller@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: "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: Jakub Kicinski <kuba@...nel.org>
> Sent: Wednesday, 29 January 2025 0:09
> To: Danielle Ratson <danieller@...dia.com>
> Cc: 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
> 
> On Tue, 28 Jan 2025 13:18:54 +0000 Danielle Ratson wrote:
> > > >         "module_state": 3,
> > > >         "module_state_description": "ModuleReady",
> > > >         "low_pwr_allow_request_hw": false,
> > > >         "low_pwr_request_sw": false,
> > > >         "module_temperature": 36.8203,
> > > >         "module_temperature_units": "degrees C",
> > > >         "module_voltage": 3.3385,
> > > >         "module_voltage_units": "V",
> > > >         "laser_tx_bias_current": [
> > > > 0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000,0.0000 ],
> > > >         "laser_tx_bias_current_units": "mA",
> > >
> > > How do you think about the units?
> > > If they may differ module to module - should we aim to normalize those?
> >
> > Not sure if I understand what you mean. What do you wish to normalize and
> how?
> 
> I don't understand the "_units" keys, basically:
> 
>         "max_power": 10.0000,
>         "max_power_units": "W",     <<
> 	[...]
>             "low_warning_threshold": 0.1585,
>             "units": "mW"           <<
> 
> or:
> 
>         "length_(smf)": 0.0000,
>         "length_(smf)_units": "km",  <<
>         "length_(om5)": 0,
>         "length_(om5)_units": "m",   <<
> 
> What are these for?
> 
> Is the consumer of the JSON output supposed to be parsing the units and
> making sure to scale the values every time it reads (e.g. divide by 1000 if it
> wants W but unit is mW)?
> 
> Or the unit is fully implied by the key, and can't change? IOW the unit is only
> listed so that the human writing the consumer can figure out the unit and then
> hardcode it?

Yes, the unit is implied by the key is hardcoded. Same as for the regular output, it should give the costumer idea about the scale.
There are also temperature fields that could be either F or C degrees. So overall , the units fields should align all the fields that implies some sort of scale.