Re: improvements

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Sep 29, 2013 at 08:32:01AM +1000, Darren Reed wrote:
> 
> Agreed, supporting VLANs with bridge(4) would be very useful.
> 
> From a certain perspectice, swconfig(8) is nothing more than the means
> throughwhich the hardware is programmed.
> 
> How does brconfig need to change in order for swconfig to not be required?
> 
> Or are further changes required, such as the device model where we have
> a"switch" that attaches to mvls0 and a "switch" that attaches to some
> softwarebridge?(Both switches would be managed using the same commands.)

That sounds right to me.  brconfig (which would become a bit of a misnomer)
should control an arbitrary L2 backend, which might be implemented by a
driver for a hardware bridge (or switch) or might be implemented by a
driver that itself implements a software bridge/switch.  This would entail
splitting the current bridge(4) driver in half.

The tricky part would be expressing in all cases how the system's
physical network interfaces are connected to the controlled bridge/switch,
if at all.  For software, sure, that's easy.  For hardware, not so much.

Also, there are hybrids, like hardware switches that kick control frames
(such as STP) out a particular port, or even out a non-Ethernet interface.
Those would need the STP implementation from bridge(4) but not other parts
of it; similarly, they might need the LACP implementation from agr(4) but
not the actual frame distribution/collection.  In fact, it's likely that
one would often need half of agr(4) to support such a switch chipset's
hardware link aggregation, while needing another instance of *all* of it
to actually get packets moving between the switch and the host...

This can get pretty confusing pretty quickly.  I've carboned one of my
former coworkers who maintains the L2 switch code where I used to work;
maybe he'll comment if he thinks it's appropriate.

Thor