Re: Fixing, reestoring DEC FDDI (DEFPA/DEFEA/DEFTA/DEFQA) in 8.2, 9.2; restore to -current?

 

On Monday, February 12, 2024 at 04:24:44 PM PST, Jason Thorpe <[email protected]> wrote:




> On Feb 11, 2024, at 1:29 PM, Jonathan Stone <[email protected]> wrote:

>> Turns out  that  fddi_ifattach() is broken in 8.2 and 9.2. [...]

> Right, it was removed from -current before netbsd-10 branched after some discussion.  Same with Token Ring, for the same reason ... a bunch of
> apparently unused code that had no work done to make MP-safe improvements like the Ethernet code received, and the work hadn't been done 
> because, well, no one was apparently using it.  Looks like I was right, because (a) no one screamed when it disappeared, 

Huh? I did, as soon as I noticed it was gone. It's taken me that long to phsyically get set up.
After Long Covid, I have difficulties carrying the Turbochannel machines that i used to pick up with one hand.

If it's unclear: yes, I'm volunteering to revive the PDQ and FDDI code, maintain it, and to do better than the
prior (ab)use of "struct ethercom" in FDDI and 802.11 driver(s). I even acquired a DEFZA-AA), with hopes of
writing a driver. (I got a copper DEFZA years ago, but never found anything compatible for the other end).


> and (b) when someone 
> tried an older version that was still around, it blew up in their face. :-)  

I'm pretty sure that was me. if it wasn't me, I also hit a crash, and IIRC, I emailed you about it.
Either way, I have the FDDI hardware set up; it's now working in 8.2 and 9.2 (working on 9.3).
And I see ways to refactor "struct ethercom" and "FDDI" handling. 

I fundamentally disagree with removal of FDDI on the basis that FDDI has been supplanted by Ethernet.
Yes, FDDI clearly *has* been supplanted by 100base-TX (and faster) Ethernet. However, NetBSD supports
several arch's for which Fast Ethernet has never been available. But some of those architectures _do_
have extant FDDI NICs. Thus, for that subset of architectures, FDDI is not redundant and not "supplanted".



> [ pdq code a twisty mase [sic] of #idefs ]

Yes, the pdq is a nasty case of #ifdef's. But if Matt Thomas isn't maintaining it, I seen no value in retaining those #ifdef's.
I'm volunteering to strip out those #ifdef's, if that's a (entirely reasonable) pre-requsite to reestoring PDQ support.
And I've set up a couple of spare "thin clients" with PCI expansion slots, which I can ship, with FDDI cards,
to anyone else who wants to help support FDDI, or in case I'm not available