On Sunday, February 11, 2024 at 10:54:31 PM PST, Martin Husemann <mar...@duskware.de> 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...
