On Sat, 1 Apr 2000, David S. Miller wrote:
> If you thought that the idea was to just make ethtool "as is" be the
> "new thing", think again and I don't know what made you think this.
Because that was specially what Jeff Garzik proposed doing. Most of the
changes he has been making have been flawed, yet I repeatedly see them go
into the kernel without question.
This exchange isn't "the 'ethtool' interface is bad", it is "stop
pointlessly breaking things". (See my final comments.)
> Act as if nobody cares about the current ABI, and changing it,
> because nobody does. See below, I don't care if ethtool were
For several years I have been actively recommending that people use
e.g. 'mii-diag -A 10baseT' to set the transceiver configuration.
Removing this capability will break the driver for the people that rely on
it.
A good example of where this is useful is for networks with CAT3 cable.
Auto-negotiation will complete, but 100baseTx communication might not be
reliable or even possible. Forcing just 10baseT results in only a half
duplex link. Forcing 10baseT-FDX results in machines that break the network
when later plugged into a repeater. The proper solution is to advertise
10baseT-{HDX,FDX}, more precisely 0x0061 or 0x4061.
> ripped out right now, _if_ there was another solution available.
> What's pertinent about ethtool is that it attempts to not make
> itself to any specific link type nor family of link types.
Being arbitrarily extensible by changing the source is not the same as
having the required feature. If anything it encourages extensive additions
by people that want to create a language around specifying the exact
transceiver behavior.
> Donald, we're proposing a totally new network device ioctl() based
> configuration mechanism. Your stuff dies outside of the scope of
> driver developer debug, my ethtool dies forever, and we have this
That's not true. The 'mii-diag' program has its name because that was its
original use. It is now typically used for setting the transceiver behavior,
although it still has features, like "-w" to monitor link state changes, to
help diagnose problems.
> new thing. It has a new ioctl number, and now here we are discussing
> how it should work and what model it should have to provide today's
> and hopefully tomorrow's needs.
I have no problem with migrating over to over to a newer model. We
specifically need new IOCTL numbers. But the Jeff Garzik was going to
rip out the old interface, just to change it. As is so often the case, Jeff
doesn't understand the code or what it might be used for.
> On a seperate topic, assuming MII is so general and covers things so
> well, why don't we have a drivers/net/mii.c which can do all of the
> generic bits of programming a MII phy? It wouldn't happen to be
> because many vendors did things just a slight bit differently such
> that dealing with all the differences is just too much of a pain
> within the scope of a generic implementation?
I've been planning something along these lines. That's why the drivers have
very similar MII read and write routines.
The BSDs have something almost like this, but implemented badly. It results
in a long laundry list of transceiver tweaks dropped into many drivers.
You can see the history from the incongruous comments.
QNX (which, link LynxOS, seems to have, ahem, code and messages identical to
my GPLed Linux driver code), reportedly uses a MII support library.
I used to ignore Jeff's code changes, expecting that people would
see that they were obviously broken. Or I would point out a few specific
problems, and expect that people would extrapolate or investigate. I've
recently been told I was just implicitly validating his changes by doing this.
My comments were read as "only two or three things need to fixed up" rather
than "it's all broken, these are a few of the obvious ways".
Perhaps this is what happened in August.
People were hearing "Fix these minor flaws. I'm actively helping to point
them out."
I was saying "Jeff Garzik's change break things, and he doesn't understand
how it needs to work. Here are a few of the major ways in which it is
flawed. I'm not going to use it in preference to my extensively tested,
proven-working approach."
Kernel development should not be done with an attitude of "lets really break
it so everyone will have to jump in and perhaps something better will come
of it."
Donald Becker
Scyld Computing Corporation, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
