Tue, Mar 26, 2019 at 06:59:32PM CET, mkubecek@suse.cz wrote:

On Tue, Mar 26, 2019 at 04:59:11PM +0100, Jiri Pirko wrote:

quoted

Mon, Mar 25, 2019 at 06:08:15PM CET, mkubecek@suse.cz wrote:

quoted

Declare attribute type constants and add helper functions to generate and
parse arbitrary length bit sets.

Hmm, this looks like a lot of work. Two things:
1) This is generic. Not really related to ethtool in any way. Could this
   be done in netlink common code?

I suppose it could if other netlink based APIs would be interested in
using it. The only ethtool specific part is the support for "legacy
style names" (fixed size strings) but that is something I'm not really
happy about.  Perhaps it's time to return to the original idea of
supporting only arrays of (char *) and creating them around existing
fixed size ones.

Wait, could you please describe this more?

quoted

2) Did you think about leveraging NLA_BITFIELD32? What I mean is this:
NEST_START
   NLA_BITFIELD32 index 0 (bit 0-31)
   NLA_BITFIELD32 index 1 (bit 32-63)
   NLA_BITFIELD32 index 2 (bit 64-95)
   NLA_BITFIELD32 index 3 (bit 96-127)
   ....
NEST_END
It is basically an array of NLA_BITFIELD32.

That would be similar to compact form but it would introduce the
interleaving and extra struct nlattr header for each block. I don't
think it would make things easier.

I'm just trying to figure out if it would be possible to use existing
building block instead of introducing new ones....

The verbose form is meant to allow requests like

 ethtool -K eth0 tx-vlan-stag-hw-insert on
 ethtool -s eth0 advertise 1000baseT/Full off

without either keeping the table of available flags in sync between
kernel and userspace (all userspace users of the API) or having to ask
for the list first (in case of one shot requests as above; long running
tools like "ethtool --monitor" or config management daemons would keep
the tables and use compact form).

Okay, I have to go over those patches but this smells.

Michal