Date: Sat, 1 Apr 2000 05:12:45 -0500 (EST)
From: Donald Becker <[EMAIL PROTECTED]>
> Adding that capability is simple, just add a "advertise" u32 to the
> ethtool_cmd structure, define a set of ADVERTISE_* bits (they can be
> the same bits as the SUPPORTED_* ones) and then one can just say:
That you can add code to add functionality is no surprise..
This is why we are discussion what it needs, and how extensible
it can be.
Act as if nobody cares about the current ABI, and changing it,
because nobody does. See below, I don't care if ethtool were
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.
No interface is going to cover all media types. But one named "ethtool"
isn't off to a good start for covering e.g. ATM. The MII-MDI standard was
flexible enough to support 1Mbps PNA transceivers without a change.
It's called ethtool due to legacyness. It can be named whatever you
want, how about netdevcfg? I could care less what the name is.
Forget about ethtool, act like it doesn't exist.
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
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.
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.
"ethtool" exists in this discussion as a model for making the
interface general enough that it can be extended whenever needed to
handle whatever funky semantics some strange networking device ends up
having in the future.
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?
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]
