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 :-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH werner.almesberger@xxxxxxxxxxx /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
|