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

Re: [RFC] ethtool semantics

From: Marc Herbert <hidden>
Date: 2004-06-07 23:58:50
Also in: lkml

On Mon, 7 Jun 2004, David S. Miller wrote:
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:

a) Yell at the user for doing something stupid.

b) Fail silently (i.e. ignore command).

c) Change advertised value accordingly and initiate new negotiation.

d) Consider "autoneg off" implied, force media accordingly.

The ethtool(8) man page I'm looking at doesn't address that question. The
actual behavior I've seen is b) which is by far my least preferred
solution.
speed and duplex fields should be silently ignored in this case
I find the c) feature very convenient. For instance it allows reliably
downgrading a link connected to a switch without having to fiddle with
the configuration of the switch, something which is usually (pick your
favourites) non-standard, painful, not authorized, not implemented,
buggy,...

Command line parameters of the bcm5700 driver do implement c) (among
other nifties). Documented in its man page. Command line parameters of
e1000 also allow some control over the autonegociation process, even
if not using c) but a different (and less user-friendly) syntax. See
Documentation/--/e1000.txt. From David's words, I suspect this feature
is simply missing from ethtool.

Finally, silently ignoring user input is not very user-friendly IMHO.
I would much prefer a) to b).

I am aware that my preferences are probably in inverse order of the
amount of work required.



PS: I read netdev but not linux-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help