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.
