> On Feb 11, 2024, at 1:29 PM, Jonathan Stone <kiwi_jonat...@yahoo.com> 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
