On Fri, 2005-27-05 at 18:35 +0200, Thomas Graf wrote:
> I do NOT agree on moving gc_ into this architecture as well,
> it doesn't belong there.
Well, you do realize they are part of the in_dev ? ;->
> Nitpicking for a bit, although inet6_dev and in_device hold
> reference to the their arp respectively ndisc parameter set,
> the sysctl interface does not use this reference but stores
> the ifindex of the netdevice, _which_ is correct I think
> because parameter sets are _not_ limited to inetdevs in terms
> of architecture but only in terms of current use.
>
I see a little main service header with ifindex always no different than
IFA or IFLINK etc followed by appropriate TLVs which are nested.
Unfortunately i still cant find the patch - i started with a different
approach; my immediate interest was to get events when someone made
in_device changes. BTW, this is going to be one of the main challenges
since there are many paths to configure these things.
> > The deafult can be overriden by devX. So they dont need to sync.
> > But this is a separate topic
>
> I was not talking about in-sync but rather that gc_* only
> appears in default/ but not in devX/. What I expect is that
> every default parameter can be overwritten in devX which
> is not true for gc_*. Which is the reason why I implemented
> them outside of the NDTPA_PARMS nested TLV.
>
Well, if you look at the structure there is no reason they should really
be separate; infact theres a comment:
-----------
struct neigh_parms parms;
/* HACK. gc_* shoul follow parms without a gap! */
int gc_interval;
int gc_thresh1;
int gc_thresh2;
----------
To me the abstraction is pretty clear. I would agree that the way
parameters configurable from user space and some of the methods may not
be the best in terms of neighbor tables organization.
> I understand your architecture and if we follow this thought
> we'd have a "default" netdevice which repesents all default
> settings.
>From looking at the code, the default stuff seems to be "hardcoded".
Example in the definition arp_tbl.
> I do agree with this architecture but the problematic
> question remains: Do we want parameters in "default" which are
> not available in devX? I think this question is what it gets
> down to in the end. If we say, yes we do want this, then we
> can implement all generic settings, such as tcp_, using this
> scheme as well. I don't disagree with this completely but I
> find it not very intuitive from a user perspective.
The model like i said is clean. There are some issues i have qualms with
- such as IP address arrangements and tight integration with netdevices
- but those can addressed at a later time.
cheers,
jamal
|