On Wed, Mar 27, 2019 at 10:57:49AM +0100, Jiri Pirko wrote:

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

quoted

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?

At the moment, there are two formats of bit name tables. Legacy format
which is used by ioctl string sets, e.g.

const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN] = {
	...
};

(the same is provided by NIC drivers with ethtool_ops::get_strings())
and simple format used for newly added string sets, e.g.

const char *const link_mode_names[] = {
	...
};

If the bitset implementation is to be used by other APIs, legacy format
support would make little sense so I would suggest to drop legacy format
support from bitset code and build a (const char **) "index" for ethtool
legacy string arrays before passing it to bitset related functions.

Michal