Date: Sat, 1 Apr 2000 01:13:44 -0500 (EST)
From: Donald Becker <[EMAIL PROTECTED]>
On Fri, 31 Mar 2000, Jeff Garzik wrote:
> DaveM pointed me to ethtool (include/asm-sparc/ethtool.h), which
> has been available on the Sparc platform for a while.
This is the standard Solaris tool. I'm gussing the reason it's on
Linux at all is to support the Sparc binary.
Not really. I did not even know about such a Solaris tool
until you mentioned it here.
I wrote and designed the whole thing from scratch without
any knowledge of other such tools on any other OS. I designed
it do exactly what I needed it to do, no more no less.
It is anything but Solaris compatability layer stuff.
Also, your MII layout argument is flawed. All of the fddi, atm,
etc. link layer devices I am aware of do not follow that model.
The model suggested by the ethtool interface is generic enough that it
can be made to fit those non-ethernet-MII-like models just fine. It
is based upon link speeds, duplex settings, etc. and the driver can
map this to whatever the hardware is really like, be it MII or some
odd-ball fddi/atm/whatever transceiver.
Finally, I want to get away from using the SIOCDEVPRIVATE ioctls
in drivers because it's nearly impossible to implement cross Linux
ABI ioctl() compatability (for example, from 32-bit user app to 64-bit
kernel) because at ioctl() time, which is where we can catch it,
there is no way to find out what types these ioctls are really passing
between the actual handler and userspace. The only other solution
is to CONFIG_COMPAT32 or whatever in each driver, no thanks.
You may think this is an insignificant issue, but now we have 4 ports
which have to address this somehow, sparc64, ppc64, mips64, and ia64.
Next, the SIOCDEVPRIVATE interface says that the user knows which
kernel driver is running eth0 vs. eth1, etc. Another sign of very
poor design.
Using ioctls which to multiple real ioctl handlers, all with different
type passing is quite unclean. At best, the SIOCDEVPRIVATE is a great
debugging hack for the driver developer, but that's where it stops, as
a hack. We really don't want to propagate this mess into what user
applications really use.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
