Re: [PATCH 06/15] batman-adv: Distributed ARP Table - add snooping functions for ARP messages

[Simon Wunderlich <simon.wunderlich-Y4E02TeZ33kaBlGTGt4zH4SGEyLTKazZ@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]

Hello David, 

we are a little bit in a pinch here - the DAT feature sent with this
patchset was developed for a long time, and we need your decision to move on
as more and more patches depend on it:

 * should we rewrite DAT to use our own ARP table/backend or
 * can we use the ARP neighbor table in another way, maybe after your changes?

We thought that re-using existing infrastructure would be smarter, but if
you disagree, please tell us so - we would like to get this feature finally
upstream and need your input to make the neccesary changes.

Thanks
	Simon


On Thu, May 17, 2012 at 07:53:54PM +0800, Marek Lindner wrote:
> 
> David,
> 
> > On Tuesday, May 01, 2012 08:59:04 David Miller wrote:
> > > From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
> > > Date: Tue, 1 May 2012 00:22:30 +0200
> > > 
> > > > However this patch also contains a procedure which queries the neigh
> > > > table in order to understand whether a given host is known or not.
> > > > Would it be possible to do that in another way (Without manually
> > > > touching the table)?
> > > > 
> > > > Instead, in the next patch (patch 06/15) batman-adv manually increase
> > > > the neigh timeouts. Do you think we should avoid doing that as well?
> > > > If we are allowed to do that, how can we perform the same operation in
> > > > a cleaner way?
> > > > 
> > > > Last question: why can't other modules use exported functions? Are you
> > > > going to change them as well?
> > > 
> > > I really don't have time to discuss your neigh issues right now as I'm
> > > busy speaking at conferences and dealing with the backlog of other
> > > patches.
> > > 
> > > You'll need to find someone else to discuss it with you, sorry.
> > 
> > I hope now is a good moment to bring the questions back onto the table. We
> > still are not sure how to proceed because we have no clear picture of what
> > is going to come and how the exported functions are supposed to be used.
> > 
> > David, if you don't have the time to discuss the ARP handling with us could
> > you name someone who knows your plans and the code equally well ? So far,
> > nobody has stepped up.
> 
> let me add another piece of information: The distributed ARP table does not 
> really depend on the kernel's ARP table. We can easily write our own backend 
> to be totally independent of the kernel's ARP table. Initially, we thought it 
> might be considered a smart move if the code made use of existing kernel 
> infrastructure instead of writing our own storage / user space API / etc, 
> hence duplicating what is already there. But if you feel this is the better 
> way forward we certainly will make the necessary changes.
> 
> Regards,
> Marek
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]