* jamal [ref] 2005-05-31 08:48

The neighbor code ought not be aware of devices; but whoever is
configuring must be. By configuring i mean "stiching together" the
different blocks (as in some netlink based program in user space). the
idevxxx is a "stiching"  construct - and therefore it may be aware of
many other things that a standalone block doesnt. One could argue that
the ifindex in a netdevice is also under the same class. The ARP, NDISC,
netdevice, filters etc are the blocks being sown together. 
Most of the times these blocks are built together in a topology that a
packet flows through. 

OK, so your idevxxx is a kind of container for various configurable
blocks that logically belong to a inetdevice and a device specific
parameter set for a neighbour table would one of these blocks?

I think this is appropriate for NDTA_PARMS, e.g. there might be
multiple of such neighbour table parameter blocks per inetdevice
identified by the name of the neighbour table. You certainly have
a good point there, I see two minor drawbacks though: a) where
do we put these parameter blocks if it doesn't belong to a
inetdevice? and b) it makes collecting the complete configuration
of a neighbour table complicated. Nevertheless, I think I can
agree on this.

I agree that we should leave the neighbor table-specific knobs out of
devconfig.  

OK, so we leave RTM_NEIGHTBL_* as-is but move the device specific
parameter sets into devconfig? i.e. RTM_NEIGHTBL_* will cover:

 * the core neighbour table configuration (key-len, entry-size,
   last-flush, gc thresholds, gc interval, hash settings, etc.)
 * the default parameter set
 * neighbour table statistics

It will help, though, for devconfig to have a single reference to the
"instance" of the table(perhaps a name or a even a 32 bit pointer
address) that a device uses (thefore maintaining the abstraction); but
since there is only one table for v4 and v6 anyways i suppose it is
implicitly assumed to be that one table.

This kind of breaks the architecture, i'd rather have it the other
way around, i.e. we hold a netdevice reference in each parameter set
and when lookup a parameter set for a specific idevxxx we iterate
through all neighbour tables and their paremter sets and compare
ifindex.