From: Bill Davidsen <davidsen@tmr.com>
To: Roger Luethi <rl@hellgate.ch>
Cc: "David S. Miller" <davem@redhat.com>,
jgarzik@pobox.com, netdev@oss.sgi.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] ethtool semantics
Date: Wed, 09 Jun 2004 17:09:04 -0400 [thread overview]
Message-ID: <40C77C70.5070409@tmr.com> (raw)
In-Reply-To: <20040608210809.GA10542@k3.hellgate.ch>
Roger Luethi wrote:
> On Mon, 07 Jun 2004 14:57:23 -0700, David S. Miller wrote:
>
>>On Mon, 7 Jun 2004 23:28:04 +0200
>>Roger Luethi <rl@hellgate.ch> wrote:
>>
>>
>>>What is the correct response if a user passes ethtool speed or duplex
>>>arguments while autoneg is on? Some possible answers are:
>>>
>
> [...]
>
>>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
next prev parent reply other threads:[~2004-06-09 21:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-07 21:28 [RFC] ethtool semantics Roger Luethi
2004-06-07 21:57 ` David S. Miller
2004-06-07 23:43 ` Marc Herbert
2004-06-08 21:08 ` Roger Luethi
2004-06-09 21:09 ` Bill Davidsen [this message]
2004-06-09 21:38 ` Roger Luethi
2004-06-09 22:12 ` David S. Miller
2004-06-14 13:11 ` Marc Herbert
2004-06-14 17:01 ` Tim Hockin
2004-06-14 19:32 ` Marc Herbert
2004-06-14 19:42 ` Roger Luethi
2004-06-10 0:01 ` James H. Cloos Jr.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40C77C70.5070409@tmr.com \
--to=davidsen@tmr.com \
--cc=davem@redhat.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=rl@hellgate.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.