----- Original Message ----- >Date: Tue, 07 Jul 2009 15:34:16 -0700 >From: "Garrett D'Amore" <[email protected]> >To: Steven Stallion <[email protected]> >Cc: [email protected], [email protected] >Subject: Re: [driver-discuss] Proposal: EOL dnet in favor of emancipated dfe > > >Generally, +1. The old dnet code is really crufty, and a PITA to work with. > >Actually, in retrospect (I didn't know this when I wrote the code), the >Macronix devices are fairly faithful clones of the Digital tulip >devices. Starting with my mxfe driver might not be a bad approach. > >However, there are some tricky issues involved for dnet, which my mxfe >driver doesn't deal with: > > 1) ROM parsing. Some NICs use a ROM to support alternative media. >That said, its probably not unreasonable to ditch support for dnet >devices that don't support either MII or NWay style 100Base-T/10Base-T. >(I.e. I think BNC and AUI support could go bye-bye.) > > 2) interrupt hackery. It turns out that some multiport dnet cards >exist that use non-compliant interrupt routing. This is something that >would probably need to be maintained, since I believe that most folks >still using dnet cards are doing so with multiport cards. (There is >little need for the dnet driver otherwise.) > >All that said, I'd just assume see dnet go bye-bye altogether. These >devices are *really* ancient; I don't think a genuine tulip part has >been sold in a *very* long time. Apart from the multiport variants, >there is no good reason anyone should be still using these devices, >IMO. There are cheap and readily available 10/100 and even gigabit >alternatives. > > -- Garrett
+1 another starting point might be my tu. It supports srom format 4.0.2, and 4 port cards. I tested it for nicdrv last summer, and it passed test 1-9, I think. But the source code is very complex. It need to be simplified and be modified to remove the support on non-required devices. BTW, which test in nicdrv dnet didn't pass? -masa > >Steven Stallion wrote: >> All, >> >> I have been working with Garrett D'Amore over the last several months to >> add in GLDv3 support to the aging dnet driver. Unfortunately dnet is in >> pretty rough shape, and a number of inherent issues (particularly with PHY >> selection in the driver) is preventing clean results from NICDRV. Now that >> Brussels and Garrett's mii work have been putback, the driver is even more >> out of date. >> >> I spoke with Garrett briefly today, and had a thought: Rather than continue >> to prop up dnet and build on a shaky foundation, I would like to see the >> driver EOL'd and replaced by a clean-room implementation (the emancipation >> driver-gate seems a good candidate until the new code can be integrated >> into ON). >> >> Assuming community approval, I am stopping NICDRV testing of the patch for >> Bug ID 6687881, although it is still available: >> http://cr.opensolaris.org/~stallion/dnet/ >> >> Thoughts? >> >> Steve >> >> > >_______________________________________________ >driver-discuss mailing list >[email protected] >http://mail.opensolaris.org/mailman/listinfo/driver-discuss _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
