On Fri, 1 Dec 2000, Francois Romieu wrote:
> Russell King <rmk@xxxxxxxxxxxxxxxx> écrit :
> [...]
> > We already have a standard interface for this, but many drivers do not
> > support it. Its called "ifconfig eth0 media xxx":
Uhmmm, it's not a standard if "many drivers do not support it".
It is very easy to hack up code to handle one or two drivers.
But you shouldn't claim the problem is fixed until the approach is tested
with all of the driver.
Hey, I'll make it easy. Find an approach that fully handles only the Tulip
and 3c59x drivers, and that is consistent.
I'll start you out: the possible 100baseTx configurations for the 3c59x
driver are SYM transceiver, MII transceiver, and "NWay" transceiver. The
latter two may use autonegotiation, only speed autosensing, or a fixed
speed. The SYM transceiver version can do static speed sensing.
[[ Note static speed sensing on the 3c595 is potentially evil. The chip
must generate 100baseTx link beat while checking for 100baseTx link beat.
This commonly hoses a 10baseT repeater with constant collisions. So does
"auto speed" mean "check for 100baseTx link beat, even though I sense
10baseT" or "do the safe thing and stick with 10baseT". ]]
> Ok. Hmmm... If I want to do something like
> 'ifconfig scc0 media some_frequency up' as I hope to set scc0 as a DCE (or
> ifconfig scc0 media auto up' for a DTE), I must teach ifconfig.c to
> distinguish Ethernet and synchrone interface based on interface.type,
> right ?
Correct. And just speed isn't good enough for Ethernet. We have 1/10HPNA,
100base-Fx,Tx,T4.
We should not just give up.
My point is that the issue isn't a trivial one.
Media selection code is the most time consuming and error prone code in many
drivers. I would have avoiding doing that work if there had been an easy
answer.
Donald Becker becker@xxxxxxxxx
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993
|