Thread (11 messages) flat view 11 messages, 5 authors, 2004-06-14

Re: [RFC] ethtool semantics

From: Bill Davidsen <hidden>
Date: 2004-06-09 21:11:22
Also in: lkml

Roger Luethi wrote:
On Mon, 07 Jun 2004 14:57:23 -0700, David S. Miller wrote:
quoted
On Mon, 7 Jun 2004 23:28:04 +0200
Roger Luethi [off-list ref] wrote:

quoted
What is the correct response if a user passes ethtool speed or duplex
arguments while autoneg is on? Some possible answers are:
[...]
quoted
speed and duplex fields should be silently ignored in this case

It may not matter much because few people care about forced media these
days. And it is debatable whether trying to guess the users intention
is a good idea (we lack means for users to manipulate autoneg results
via advertisted values but that's no big deal).
It does sometimes matter, because even these days we sometimes see a 
case where a brand name switch (like Cisco) and a brand name card 
(Intel, 3COM) negotiate but just don't "work right" later. In those 
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.
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!

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help