[Top] [All Lists]

Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???

To: greearb@xxxxxxxxxxxxxxx (Ben Greear)
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Werner Almesberger <almesber@xxxxxxxxxxx>
Date: Tue, 13 Jun 2000 10:21:27 +0200 (MET DST)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <3945A2F0.A93D09BA@xxxxxxxxxxxxxxx> from "Ben Greear" at Jun 12, 2000 07:56:48 PM
Sender: owner-netdev@xxxxxxxxxxx
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
 - 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

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 /

<Prev in Thread] Current Thread [Next in Thread>