Re: [RFC] ethtool semantics

[Roger Luethi <rl@hellgate.ch>]

On Wed, 09 Jun 2004 17:09:04 -0400, Bill Davidsen wrote:
> cases forcing on both ends or just the NIC end results in a fully 
> functional connection.
> 
> We usually do this with module parameters, but do use ethtool (or 
> mii-tool) on occasion.

<sigh> I just killed the module parameters in my via-rhine development
tree. I suppose you don't use via-rhine!? :-) Nobody complained when
the code was broken for the longest time, and the current design has
all kinds of issues, not the least of which is a distinct lack of sane
semantics for stuff like hotplug, interface renaming, etc.

I'd prefer not to spend my time writing a clean implementation (or fixing
up the current one) of a mechanism that is conceptually obsolete.

> >However, "silently ignoring" strikes me as a very poor choice, in
> >stark contrast to Unix/Linux tradition. A user issues a command which
> >cannot be executed and gets the same response that is used to indicate
> >success!? What school of user interface design is that? How is that
> >not confusing users? </rant>
> 
> Yah.
> 
> Seeing this happen while autonegotiation is in progress is a small and 
> unlikely window of course!

Hmm? It's not about autoneg being in progress, and it's not a race
of any kind. If your NIC comes up with nway autoneg enabled, you must
use ethtool to explicitly turn autoneg off before you can use ethtool
duplex/speed options to force a media mode. However, if you try to force
media with autoneg still enabled, your command will be silently ignored.
It's up to the user to find out that the command failed and why.

Roger