Werner Almesberger wrote:
>
> Ben Greear wrote:
> > So how about we call it a circuit, and then use a struct net_device to hold
> > the circuit information? Since it walks, looks, and quacks like an ethernet
> > device, we could just put it in the same kernel management structures that
> > hold the other ethernet devices... :)
>
> Hmm, I'm afraid it might turn out to be more like a neighbour than a
> net_device ...
>
> I think the underlying problem of this discussion is that the current
> net_device is heavily overloaded. Let's see, there are:
>
> - a set of local L3 addresses
> - a local L2 address (with VLAN, that would be multiple ?)
> - a set of potentially reachable L3 addresses
> - a set of actually reachable (connected) L3 addresses, along with
> the correspnding L2 addresses
> - a set of methods to translate L3 to L2, possibly manipulating the
> packet content (ARP)
> - a queuing discipline
> - maybe a physical device
> - an application-visible device (e.g. selected by address in bind(2))
> - a few references from the routing table
> - initial information for more specific structures, e.g. the mtu for
> destinations
> - per-net_device state (e.g. flags)
> - statistics
> - typically one or more communication channels (e.g. Ethernet link or
> ATM VCs)
> - a name, used for management
> - an index, e.g. used for multicast socket options
> etc.
>
> No surprise it's nearly impossible to agree on a reasonable way to add
> some major new functionality :-)
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 :)
It would be a perfect place for OO and inheritance, if we were into that,
but since that isn't an option, seems to me the logical choice is to
add a poiner to the end of the struct and put your specialized stuff
there. (That's what I did for VLAN at least.) That has the unsavory
result of adding cruft to the net_device struct, but with some clever
use of DOCUMENTED flags in the net device, we could probably do run-time
casting of a void* or two to hold information for various, mutually exclusive
data structures.
For example, a net_device should never need both VLAN info and ATM_PVC info,
so one void*, with a flag to tell what type it is, should be sufficient.
Basically, just hand-coded inheritance...
Ben
--
Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
|