Messages in this thread | | | Date | Tue, 26 Mar 2019 18:59:32 +0100 | From | Michal Kubecek <> | Subject | Re: [PATCH net-next v5 07/22] ethtool: netlink bitset handling |
| |
On Tue, Mar 26, 2019 at 04:59:11PM +0100, Jiri Pirko wrote: > Mon, Mar 25, 2019 at 06:08:15PM CET, mkubecek@suse.cz wrote: > >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.
> 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.
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).
Michal
| |