netdev
[Top] [All Lists]

Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: Thomas Graf <tgraf@xxxxxxx>
Date: Fri, 27 May 2005 14:15:03 +0200
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <1117192464.6688.3.camel@xxxxxxxxxxxxxxxxxxxxx>
References: <20050526185306.GW15391@xxxxxxxxxxxxxx> <20050526185526.GZ15391@xxxxxxxxxxxxxx> <1117192464.6688.3.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* jamal <1117192464.6688.3.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-27 07:14
> It would have been better, IMO, to just work on a generic idev/devinet
> retrieval and setting instead of one component (as in ARP in this
> case). 

I thought about adding a devinet component to allow retrieving/setting
device specific parameters (along with other settings) but dropped the
idea because I did not want to implement the data structures twice.

I think this is cleaner, it allows one request to be sent to see
the complete arp/ndisc configuration rather than sending one to
retrieve the global configuration/statistics and another one
to retrieve device specific parameters.

Nevertheless, I'm open for changes so once I've written the devinet
component to change rp_filter, forwarding, arp_filter, etc. we can
still move the device specific NDTA_PARMS to the devinet component
if we still think it would be better. For now, the neightbl component
is clean, small, well defined and probably never needs to be touched
again.

Is that acceptable for you?

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