netdev - RE: [PATCH ethtool-next v3 10/16] qsfp: Add JSON output handling to --module-info in SFF8636 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:
 <DM6PR12MB4516013FA5B26F8519499CDAD8F72@DM6PR12MB4516.namprd12.prod.outlook.com>
Date: Wed, 5 Feb 2025 11:41:29 +0000
From: Danielle Ratson <danieller@...dia.com>
To: Petr Machata <petrm@...dia.com>, 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 v3 10/16] qsfp: Add JSON output handling to
 --module-info in SFF8636 modules

> From: Petr Machata <petrm@...dia.com>
> Sent: Wednesday, 5 February 2025 13:33
> To: Jakub Kicinski <kuba@...nel.org>
> Cc: Danielle Ratson <danieller@...dia.com>; 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 v3 10/16] qsfp: Add JSON output handling
> to --module-info in SFF8636 modules
> 
> 
> Jakub Kicinski <kuba@...nel.org> writes:
> 
> > I think the description fields need to either be concatenated, or an
> > array.
> 
> Yep.
> 
> https://www.rfc-editor.org/rfc/rfc8259#section-4 :
> 
>    The names within an object SHOULD be unique.
> 
>    An object whose names are all unique is interoperable in the sense
>    that all software implementations receiving that object will agree on
>    the name-value mappings.  When the names within an object are not
>    unique, the behavior of software that receives such an object is
>    unpredictable.  Many implementations report the last name/value pair
>    only.  Other implementations report an error or fail to parse the
>    object, and some implementations report all of the name/value pairs,
>    including duplicates.

OK, will fix.