> months ago, and it appeared to not be actively supported. A glance at
I'm afraid that at the moment, the best I can manage is that de4x5 is on
maintenance. Work and family commitments preclude any development work.
> the code indicates that Nway is missing, but that's just a glance.
Nway is in for all chips except the 2104[01] in which it was either not
implemented on the chip or broken on the chip.
> Digital chips, but works with relatively few boards. So you have a driver
> that claims boards that it doesn't work with (and it doesn't know it won't
> work).
Anyone who can't get de4x5 to work for them merely switches to tulip.c
(or vice versa). I would point out that there are many instances where
de4x5 has worked for people where tulip.c hasn't.
Still if there's an issue of kernel bloat and one driver has to go, I'd
reluctantly suggest the de4x5 goes only for the reasons outlined above:
that I can't spend time developing and testing into the forseeable
future due to other commitments. But then try explaining that to
existing users...
> The most complicated parts are those driven by changes in the real Digital
> chips and design recommendations, not by the clone chips. The biggest,
> ugliest chunk of code is parsing the media selection in the EEPROM, which was
> revised endlessly by Digital and is shared by most chip types, but not used
> by all boards.
Amen to that!
> Note that I don't personally think the tulip driver is all that confusing,
> there are certainly much worse drivers out there. It just came up as an
> example by Richard as being prone to break in subtle ways, and splitting
> up the parts that break and making them more independent of each other is
> probably a good maintenance strategy.
Your example (media sense algorithm barfing) unfortunately highlights a
real problem: reliance on other hardware to do the Right Thing. There's
a lot of broken PHY/MAC chips out there and autosense/Nway is no
exception - it even included the DECchips when they were first out (but
still in use). The media sense algorithms are bound to break with some
hardware combinations without special casing them, which makes the
driver even less understandable (look at the "official" DEC driver
source code from Digital [R.I.P.] to see what I mean).
Regards,
Dave
-- --------------------------------The Rich Tapestry of Life is Fraying . . .
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/