Messages in this thread |  | | Date | Wed, 20 Sep 2000 20:55:48 +1100 | From | Andrew Morton <> | Subject | Re: PATCH 2.4.0.9.2: export ethtool interface |
| |
Donald Becker wrote: > > On Tue, 19 Sep 2000, Andrew Morton wrote: > > > > This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private > > > domain of the sparc ports into include/linux. This publishes an > ... > > This is good. It would be useful to have this in place ASAP so driver > > authors have something to look at and to work against. > > You all know my opinion on this interface: it is bad.
Yes and no. I assume you refer to the ability to force link speed, duplex, etc? This is a broken way to fix broken hardware/software and I wouldn't expect many drivers to implement this part.
But the ability to talk to the driver directly, to have a uniform interface to query the link state, the link settings, to be able to tune driver-specific settings, to fetch driver-specific performance data and to dynamically change the driver debug level would be pretty useful.
> > * There don't seem to be enough port types and transceiver types. > > 10base2? BNC? 100baseTx/100baseFX? > > 1Mbps HomePNA? 10Mbps HomePNA? (Check the control words for the PNA spec.) > Various 802.11? > 10Gb Ethernet? Have you looked at gigabit autonegotiation?
Not at all, and I suspect that an attempt to define all this stuff up-front will come unstuck.
> If you are proposing a new interface (and obviously tossing the > existing MII-MDIO emulation that has existed for a few years) you should at > least support current hardware.
Well, if the driver supports SIOCGMIIPHY then the userland support library should be able to sort these things out. As far as reporting on interface settings, I'd view this proposal as allowing individual drivers to fill in any gaps. But the proposal goes further than this.
Anyway. Jeff, this smells to me like 2.5-food. This interface won't be proven and stabilised until a couple of dissimilar drivers have actually used it, and the userland stuff is implemented. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |