Donald Becker wrote:
> On Sat, 1 Apr 2000, David S. Miller wrote:
> > 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.
> Because that was specially what Jeff Garzik proposed doing.
Sorry, read the mail again. This is not correct.
The ONLY suggest kernel change was to move ethtool.h into
include/linux. I fail to see how that breaks anything at all.
Now we are having a discussion of this interface. Cool. That's how
open source and kernel development occurs -- with open discussion.
> For several years I have been actively recommending that people use
> e.g. 'mii-diag -A 10baseT' to set the transceiver configuration.
> Removing this capability will break the driver for the people that rely on
> it.
Very few rely on it. It doesn't exist in any Linux distro AFAIK. I
knew about it but it is NOT common knowledge. Most people just expect
their eth drivers to simply work, and for the most part they do. For
others, they use module options to accomplish their goals.
> > 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.
>
> I have no problem with migrating over to over to a newer model. We
> specifically need new IOCTL numbers. But the Jeff Garzik was going to
> rip out the old interface, just to change it.
re-read my mail. There was NO mention of ANY code removal.
> > 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?
>
> I've been planning something along these lines. That's why the drivers have
> very similar MII read and write routines.
The original genesis of the discussion was that I sent DaveM e-mail
about making media advertisement and setting a bit more general. My
suggestion was to use mdio_{read,write} and similar even for cards w/o
MII transceivers, like the RTL-8139. DaveM pointed me to ethtool ;-)
;-)
> I used to ignore Jeff's code changes, expecting that people would
> see that they were obviously broken. Or I would point out a few specific
> problems, and expect that people would extrapolate or investigate. I've
> recently been told I was just implicitly validating his changes by doing this.
> My comments were read as "only two or three things need to fixed up" rather
> than "it's all broken, these are a few of the obvious ways".
>
> Perhaps this is what happened in August.
> People were hearing "Fix these minor flaws. I'm actively helping to point
> them out."
>
> I was saying "Jeff Garzik's change break things, and he doesn't understand
> how it needs to work. Here are a few of the major ways in which it is
> flawed. I'm not going to use it in preference to my extensively tested,
> proven-working approach."
1) I will HAPPILY step aside as any driver maintainer if someone better
and ACTIVE wants to maintain the kernel driver(s).
2) Many of your problems seem to stem from a dislike of change, or a
dislike of the new kernel 2.3.x interfaces. To me this is a non-issue
when you don't participate in development of new kernels.
3) You know network cards better than I do. I know kernel 2.3.x better
than you do. It seems like we should work together not apart.
4) All you have to do is point out something is known broken. A bug
report. Saying "all my changes are broken" is not only wrong (many
changes clearly work from the positive feedback I get) but also
non-productive.
Regards,
Jeff
--
Jeff Garzik | Tact is the ability to tell a man
Building 1024 | he has an open mind when he has a
MandrakeSoft, Inc. | hole in his head. (-random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
