Re: [RFC] ethtool semantics

[Roger Luethi <rl@hellgate.ch>]

On Mon, 14 Jun 2004 10:01:38 -0700, Tim Hockin wrote:
> On Mon, Jun 14, 2004 at 03:11:15PM +0200, Marc Herbert wrote:
> > > That is absolutely the correct thing to do, module parameters for
> > > link settings are %100 deprecated, people need to use ethtool for
> > > everything.
> > 
> > This is precisely the reason why I am concerned about having "rich"
> > ethtool semantics. A unified, standard interface is great,... as long
> > it does not leave behind some features, like setting the advertised
> > values in autoneg. As a user of these features, I hope driver
> > developers will NOT remove those module_param features that cannot
> > migrated to ethtool.
> 
> So propose a sane semantic that handles all three cases:
> * autoneg on
> * autoneg off
> * autoneg on but limited

My first thought was if a command contains speed/duplex settings
and autoneg is on, manipulate advertised value; if autoneg is off,
force mode. That's not possible due to the way ethtool interacts with
the kernel: It doesn't request a change in a specific field. Instead,
ethtool reads all fields, flips the values it wants to have changed,
then issues a set request for everything (speed, duplex, autoneg,
etc.). In other words: speed/duplex fields are set for every call.

One way out would be to have an explicit third option, say autoneg mask.

That would give:
autoneg on + speed/duplex -> error (only userspace/ethtool can do this!)
autoneg off + speed/duplex -> force mode (driver)
autoneg mask + speed/duplex -> change advertised value (driver)

Many drivers would only support one of these two methods (force mode
presumably), so we'd have to either throw an error if an unsupported
method is requested, or print a notice and use the supported method to
force the requested mode.

Roger