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 <or...@autistici.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 >
signature.asc
Description: Digital signature