Re: [PATCH net-next v8 05/19] net: ethtool: add new ETHTOOL_GSETTINGS/SSETTINGS API

[David Decotigny]

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 <ben@xxxxxxxxxxxxxxx> wrote:
> On Tue, 2016-02-09 at 16:29 -0800, David Decotigny wrote:
>> From: David Decotigny <decot@xxxxxxxxxxxx>
>>
>> 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.