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

[Jonathan Stone]

[[cc'ed to thropejj as the lst person I know whotouched the PDQ code.  tech-net 
for discussion of refactoring ether_ifattach ]]

I'm nearing the end of reviving some DECstations and a few Vaxes.  One of the 
things I need/want for them is FDDI.
FDDI -- from the DEC "pdq"-based boards -- is the fastest, cheapest, and most 
readily available 100Mbit tecnoligy for Turbochannel and EISA.

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.

A minimal-touch fix is straightfoward; see attached diff against NetBSD-8.2.  
(Should work against 9.2, haven't tested yet).
After applying this to 8.2 kernel source and rebuilding, I have a pair of 
back-to-back, dual-attach DEFPAs (PCI FDDI).
I statically configure IP (v4) via /etc/ifconfig.fpa.  They happily ping each 
other, I can ssh across the FDDi interface, etc.

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. 

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...

--Jonathan







fix-8.2-pdq.diff
Description: Binary data

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

[Martin Husemann]

On Sun, Feb 11, 2024 at 09:29:22PM +, Jonathan Stone wrote:
> 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.

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, see the thread (if you can call it that) on tech-net
from September 2022, Subject: (non-)Equivalence of if_type == IFT_ETHER and
(struct ethercom*) == (struct ifnet*)

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.

Anyway, I am all for a cleaner overall separation of struct ethercom all over
our network code.

Martin