On Wed, 2 Aug 2006 11:02:20 +0200 Christophe Devriese <[EMAIL PROTECTED]> wrote:
> On Tuesday 01 August 2006 19:21, you wrote: > > John W. Linville wrote: > > >>>I'm just not sure that cleverness is worth the headache, especially > > >>>since the most clever things usually only work by accident... > > >> > > >>Or, work by solid, modular design and small tweaks! > > > > > > Point taken. But stashing little hacks in the networking core for > > > specific virtual drivers isn't totally modular either. And even if > > > it were, "modular design" probably belongs on the list of "things > > > that can be taken too far", like "everything in userland", "never > > > use ioctl", and "microkernels are superior". :-) > > > > To be honest, I'm not over-joyed to see bridging hooks included > > in the VLAN code..but if that is what it takes to get bridging > > and VLANs to play well and be flexible, I think it is a fair price. > > > > It certainly wouldn't hurt to have someone take a holistic view of the > > various L2 device interactions. Just documenting current functionality > > on, say, the netdev wiki would be a good first step. > > Ultimate flexibility could be provided by making the netif_rx routine (and > the > others, including vlan etc), a "virtual" routine. > > That way a list of "filters" could be defined that allow any processing to be > done on the packet before it is handed of to the linux kernel's higher > layers, including not delivering it on that interface, or delivering it on > another interface. > > This would allow very complex implementations including stuff like a > high-level l2 bridge, with vlan support, and a number of protocols like rstp, > pvst+, ... with relatively simple code, that could be isolated from the main > kernel. > > Would anyone be interested in signing off on such a patch ? (which basically > creates netif_rx and vlan_acc_netif_rx lists in the net_device structure, and > then modify bridging and bonding drivers to just use this) I have thought about this, but you end up reinventing System V streams. The problem is for simple up/down call, the stacking model works fine but once you add flow-control and multiplexing issues the problem becomes complex. It is hard to think of a good general solution where the performance wouldn't end up sucking. -- Stephen Hemminger <[EMAIL PROTECTED]> "And in the Packet there writ down that doome" - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
