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
|