netdev
[Top] [All Lists]

Re: [RFC] ethtool semantics

To: Marc Herbert <marc.herbert@xxxxxxx>
Subject: Re: [RFC] ethtool semantics
From: Tim Hockin <thockin@xxxxxxxxxx>
Date: Mon, 14 Jun 2004 10:01:38 -0700
Cc: netdev@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.58.0406141458270.16762@fcat>
References: <20040607212804.GA17012@xxxxxxxxxxxxxx> <20040607145723.41da5783.davem@xxxxxxxxxx> <20040608210809.GA10542@xxxxxxxxxxxxxx> <40C77C70.5070409@xxxxxxx> <20040609213850.GA17243@xxxxxxxxxxxxxx> <20040609151246.1c28c4d9.davem@xxxxxxxxxx> <Pine.LNX.4.58.0406141458270.16762@fcat>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2i
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



<Prev in Thread] Current Thread [Next in Thread>