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]
Date: Tue, 12 Mar 2024 10:01:05 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Donald Hunter <donald.hunter@...il.com>, Jiri Pirko <jiri@...nulli.us>
Cc: Hangbin Liu <liuhangbin@...il.com>, netdev@...r.kernel.org
Subject: Re: How to display IPv4 array?

On Tue, 12 Mar 2024 16:04:56 +0000 Donald Hunter wrote:
> > "nested-array" would tell the parser to expect a nest that has attr
> > type of value of array index, "type" is the same for all array members.
> > The output will be the same as in case of "multi-attr", array index
> > ignored (I don't see what it would be good for to the user).  
> 
> I'd say that this construct looks more like nest-type-value

type-value is sort of a decomposed array, if we have all the entries
under one nest I reckon array extension may be more appropriate.

My gut feeling is that we should generalize the array-nest type,
when I wrote the initial spec we didn't have sub-type. How about
we replace array-nest with indexed-array (good name TBD), and instead
of assuming the value is always a nest pass the type via sub-type?

For bonding probably something like:

  -
    name: linkinfo-bond-attrs
    name-prefix: ifla-bond-
    attributes:
      -
        name: arp-ip-target
        type: indexed-array
        sub-type: u32
	byte-order: big-endian

how does that sound?

exiting array-nests would change from:

 -
   name: bla
   type: array-nest
   nested-attributes: bla-attrs

to

 -
   name: bla
   type: indexed-array
   sub-type: nest
   nested-attributes: bla-attrs

But that'd mean updating all existing specs and codegen.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ