Date:   Thu, 15 Jun 2000 07:24:15 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Werner Almesberger <almesber@lrc.epfl.ch>
cc:     Ben Greear <greearb@candelatech.com>, netdev@oss.sgi.com
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
In-Reply-To: <200006131445.QAA18667@lrcsun15.epfl.ch>
Message-ID: <Pine.GSO.4.20.0006150710590.10011-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk


On Tue, 13 Jun 2000, Werner Almesberger wrote:

> Ben Greear wrote:
> > Yep, there is a comment in the code, probably from 1.x talking about how it
> > should be cleaned up in the 'next' release...seems that comment is still
> > valid :)
> 
> Oh, a _lot_ got cleaned up in 2.3 ... ;-)
> 
> > It would be a perfect place for OO and inheritance,
> 
> The "all in one" type of object you're describing would be rather ugly,
> IMHO. Better to remove those elements that don't have a 1:1 relationship
> and put them elsewhere. E.g. neighbours are already elsewhere. Local
> addresses (L3 and maybe also L2) should probably also go elsewhere.
> Then qdiscs (think multilink PPP, ATM, or FR SVCs), etc.
> 
> Probably the best approach to clean up the design would be to split the
> net_device structure into as many substructures as possible, create new
> name spaces, where applicable, and then to combine those things that
> always or usually occur together.


So you provide ability to do name spaces for the substructures/subsystems
as well? This way maybe  you can have generic and extensible user space
tool(s) modelled after the device and its 'subsystems'
The neighbor, for example, is a device 'packet mungler' -- or that is what
i claim; it maintains its own table(s), search algorithms as well as
methods. So the VLAN or MPLS etc 'subsystem' could be along the same
line. The should be a generic way for the subsystems to inter-act and
communicate eg a vlan updating the ARP table or looking up a route. 

cheers,
jamal