James Carlson wrote:
> Darren J Moffat wrote:
>
>> Garrett D'Amore - sun microsystems wrote:
>>
>>> elxl is a closed source driver supporting certain legacy ethernet cards
>>> from 3Com. (The 3c905 line, and a few compatible family members.) Note
>>> that these NICs were not used on any Sun branded equipment, and have not
>>> been popular for many years. They are still available from
>>> discounters who
>>> have been selling refurbs and surplus, but are no longer
>>> manufactured. (3Com
>>> stopped offering these products in 2006.)
>>>
>> Given how widespread these were and the fact it is/was also a well
>> supported network device on Linux and *BSD I'm a bit nervous about
>> removing support for this. The reason I have this card is because it
>> is/was well supported.
>>
>> I still have an OpenSolaris machine running snv_129 with a card driven
>> by elxl in it (100BASE-TX not 10BASE-2 or 10BASE-T). Yes it is old and
>> yes I could afford to buy a newer card (there is actually a second card
>> driven by rlts in the machine) but why should I have to ?
>>
>> Is this driver actually holding back other work ? Or is it just old and
>> not getting to benefit from new features ? If it isn't holding other
>> things back I'm not sure there is good motivation for an EOF and
>> removal. I understand the desire to remove any 10BASE-2 or 10BASE-T
>> support but there are cards out there driven by this driver that support
>> 100BASE-T (3Com 3c905B 100BaseTX Cyclone, 0x9055).
>>
>
> Indeed. And were are some test fixtures within Sun (likely still in use
> for IPMP) that depended on elxl -- because it was cheap, easy, and worked.
>
> What worries me more, though, are the odd chip vendors who reuse those
> old cores for new system-on-a-chip sorts of designs. We've run into
> that problem before (the GLDv0 EOF nuked support for several brand-new
> but obscure motherboards, despite the apparent obsolescence of the
> original stand-alone cards), and it wouldn't be good to encounter it
> again. These problems are almost always completely unfixable once found.
>
> If it must be removed for some reason, I think it'd be good to have a
> replacement developed.
>
elxl as it stands today suffers from a few significant flaws:
1) No support for automatic link negotation/reporting. This means it
won't work with nwam.
2) No support for full MTU vlans.
3) Closed source.
Addressing any of these complaints will be a costly endeavor. It is not
free to keep this around. When I modified the MII framework, I had to
modify this driver so it could use a "private" copy of the much older,
cruftier, MII bits. (Its like making a driver keep a private copy of
GLDv0 around in its own code tree.)
I knew this EOF would be contentious, but I don't think anyone is still
using this part in new systems, or has done so in quite some time. I'd
be rather shocked to hear of anyone using a 3com core in a new SoC given
that there are so many other simpler, and cheaper, solutions available.
(RTL8139 and dnet "clones" seem to be the most common from my experience
in the embedded systems arena.) Further, I'm pretty sure that 3com is
still pretty protective of their IP in this arena (for what reason I
can't imagine.)
Additionally, I think this driver gets ~0 support. Indeed, I don't have
any of the "newer" MII capable 3com parts ready at hand, but only older
non-MII versions (3c900-TPO, which is 10 Mbps only for example.) Its
now non-trivial to perform support for these parts.
Finally, there is a community alternative available, that is not
integrated into ON. Murayama has written an alternative driver, but
I've not spent any time with it.
From my perspective, I just don't see these parts as continuing to be
relevant enough to warrant any significant development effort spent on
their behalf.
- Garrett
