Sure, I will send an update:

struct ethtool_link_settings {
        __u32   cmd;
        __u32   speed;
        __u8    duplex;
        __u8    port;
        __u8    phy_address;
        __u8    autoneg;
        __u8    mdio_support;
        __u8    eth_tp_mdix;
        __u8    eth_tp_mdix_ctrl;
        __s8    link_mode_masks_nwords;
        __u32   reserved[8];
        __u32   link_mode_masks[0];
};

(+ same renaming for the ioctl sub-cmds)

that would still replace GSET/SSET/ethtool_cmd.

would that be ok?

Or, just to make sure: would you rather keep GSET/SSET/ethtool_cmd as
now for everything but the link mode masks (that would be marked as
deprecated), and have only a new command G/SLINK_MODES + struct
ethtool_link_mode_support that would only take care of the link mode
masks?

On Fri, Feb 12, 2016 at 5:49 PM, Ben Hutchings [off-list ref] wrote:

On Tue, 2016-02-09 at 16:29 -0800, David Decotigny wrote:

quoted

From: David Decotigny <redacted>

This patch defines a new ETHTOOL_GSETTINGS/SSETTINGS API, handled by
the new get_ksettings/set_ksettings callbacks. This API provides
support for most legacy ethtool_cmd fields, adds support for larger
link mode masks (up to 4064 bits, variable length), and removes
ethtool_cmd deprecated fields (transceiver/maxrxpkt/maxtxpkt).

[...]

I previously asked you to include 'link' in the command names and
structure name.  This would clarify that these are now only for link
settings and reduce the risk of confusion between old and new commands.
However, you didn't reply to that review.  Do you have any objection to
doing this?

Ben.

--
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.