On Fri, 31 Mar 2000, David S. Miller wrote:
> 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 MII model has provisions for other types, but AFAIK it's only used
for Ethernet-like framing. It is flexible enough for PNA and fiber
transceivers, so it's not exactly limited. I'm guessing that >99% of
managed transceivers use MII.
FDDI is a red herring, since it only uses fiber (despite the 100baseTx
physical layer being originally designed as copper replacement for FDDI).
> 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.
How do you specify "advertise 10baseT (half and full duplex), and 100baseTx
(half duplex)".
> 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.
It would be good to have an assigned ioctl name. This interface has existed
for years, with many drivers using it.
(I hope you are only suggesting using different constants for each size
model. Using the BSD-style encoding of ioctl lengths in the constant is a
insufficient solution to the problem of unknown passed types.)
> Next, the SIOCDEVPRIVATE interface says that the user knows which
> kernel driver is running eth0 vs. eth1, etc. Another sign of very
> poor design.
Please explain. You must have some way to name the interface before you can
ask for its status.
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]
