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 wrote: > On Feb 11, 2024, at 1:29 PM, Jonathan Stone 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
Re: Fixing, reestoring DEC FDDI (DEFPA/DEFEA/DEFTA/DEFQA) in 8.2, 9.2; restore to -current?
On Sunday, February 11, 2024 at 10:54:31 PM PST, Martin Husemann wrote: >We have a simmilar problem with net80211, where we are required to have a > (mostly unused) struct ethercom for each virtual interface (in the new stack) >just because of initialization and to be able to use vlan(4) on a > wifi interface, [...] https://mail-index.netbsd.org/tech-net/2022/09/28/msg008338.html > Now I don't know if vlan(4) is important for FFDI and probably bpf(4) users > are not expecting ethernet frames from it, so things might be easier. My recollection is that FDDI was "mature techology" (development stoped, effectively legacy) when 100Mbit Ethernet became available. Plus, it's a ring topology, so VLANs didn't give as much utility as with switched Ethernet. Curiously enough, the use-case of "struct ethercom" which the "pdq" (fpa, etc) FDDI driver hit, was adding multicast addresses when an interface comes up. How much of the "struct ethecom" pain would be fixed by having a common struct containing _just_ the "multicast" data structures? That still leaves vlan; and separating vlan from multicast would (I assume) require separate locks. Or more ugly struct overlaying...
Re: Fixing, reestoring DEC FDDI (DEFPA/DEFEA/DEFTA/DEFQA) in 8.2, 9.2; restore to -current?
> On Feb 11, 2024, at 1:29 PM, Jonathan Stone wrote: > Turns out that fddi_ifattach() is broken in 8.2 and 9.2. It never > initialises sc_ec.ec_lock, which causes a panic the fisrt time the kernel > tries to add a multicast address to the interface. If you're using IPv6 (I > don't; I comment out "options INET6"), the panic occurs soon after boot when > ipv6 discovery starts. ^^^ Important context. > I would like to restore "pdq" (fpa, fea, fta, whatever a qbus attachment is; > or write one if none) to -current. > However, 10_RC4. doesn't even have if_fddisubr.c. 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, and (b) when someone tried an older version that was still around, it blew up in their face. :-) Anyway, having that unmaintained code lying about introduces a practical barrier to making further improvements to the networking code, especially when those improvements introduce changes to the contracts between the layers. In the case of the FDDI code, there's the additional complication that the PDQ driver is ... well, it's something! Namely, a maze of twisty #ifdefs, all alike, where you stand a very good chance of being eaten by a grue. > I don;t want to re-create the hack of having two different initialisers for > the IEE 802 (sic) [*] portions of "struct ethercom'. > A cleaner solution is to declare a new struct with all the members of 'struct > ethercom', except the 'struct ifnet ec_if; > 'struct ethercom' then becomes a struct with two members: a struct ifnet, and > the new struct (struct iee802_common?). > That allows clean separation of code which manipulates the additions in > today's "struct ethercom', from code which also manipulates struct ifnet. > > Thoughts? Anyone actively against PR'ing and (hopefully) minimal patches > NetBSD-8 and NetBSD-9? > Or against restoring FDDI to -current. (and perhaps backporting to NetBSD-10)? > If I have to, I can probably ship a pair of DEFTAs to an interested > contributor, if support from me is too tenuous. > > [*] FDDI is not IEEE 802. But it's derived from Token Ring,, 802.5, which is. > And I suppose the refactoring I'm proposing here could add supporing Token > Ring, if anyone actively wanted to... See also about Token Ring above :-) I am not at all opposed to resurrecting this stuff, doing a re-factor to make it easier to maintain going forward, etc. If someone wants to volunteer to do that work (and then actually DO it), who am I to say no? After all, I love obsolete technology as much as (and quite possibly more than) the next guy! *Stares in 6800.* But I would prefer we not return to the previous state where the code went completely unmaintained and unused. -- thorpej
